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ABSTRACT 



This thesis describes the potential use of a general-purpose controller autonomously 
to measure acoustic vibration in the Space Shuttle Cargo Bay during launch. The ex- 
perimental package will be housed in a Shuttle Get Away Special (GAS) canister. 

We have implemented the control functions with software written largely in the C 
programming language. We use an IBM MS DOS computer and C cross-compiler to 
generate Z-SO assembly language code, assemble and link this code, and then transfer it 
to EPROM for use in the experiment's controller. The software is written in a modular 
fashion to permit adapting it easily to other applications. The software combines the 
experimental control functions with a menu-driven, diagnostic subsystem to ensure that 
the software will operate in practice as it does in theory and under test. 

The experiment uses many peripheral devices controlled by the software described 
in this thesis. These devices include: a solid-state data recorder, a bubble memory 

storage module, a real-time clock, an RS-232C serial interface, a power control subsys- 
tem. a matched filter subsystem to detect activation of the Space Shuttle’s auxiliary- 
power units five minutes prior to launch, a launch detection subsystem based on 
vibrational and barometric sensors, analog-to-digital converters, and a heater subsystem. 
The matched filter design is discussed in detail in this thesis, and the results of a com- 
puter simulation of the performance of its most critical sub-circuit are presented. 
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GLOSSARY 



Analog-to-digital (A/D) Converter: Analog signals are signals whose levels vary con- 
tinuously as a function of time. Digital signals are signals which take on discrete 
(quantized) values, and these values remain constant for some given period of time, 
at which time the level is updated. An analog-to-digital converter samples a contin- 
uous input signal, decides which of a finite set of discrete values is the best one to de- 
scribe the input signal, and outputs that discrete value. A regular clock is used to 
cause the input to be sampled again on a repetitive basis, and the output likewise is 
updated at the same rate. A digital computer cannot deal with continuous signal lev- 
els, so A D converters are routinely used to let such computers read signal levels in the 
form they can handle, as digital values. 

Auxiliary Power Unit (APU): The APUs are jet-turbine-powered engines used during 
both launch and recovery to operate the control surfaces of the space shuttle. Because 
they have a limited amount of fuel, the mission will be scrubbed if they operate for 
more than seven minutes before launch. The Vibro-acoustic Experiment attempts to 
detect them. If it is successful in doing so. it can anticipate launch. 

ASCII: American Standard Code for Information Interchange. This is a seven-bit 
data code used in many digital systems to represent alphabetic and numeric characters, 
punctuation marks and a number of non-printing characters commonly used to pass 
information from one device to another. Since most digital systems are based on 
eight-bit bytes, one bit. the high-order one. is unused in the ASCII scheme. It is not 
uncommon for manufacturers to appropriate the extra bit for their own purposes. 

BAUD: The baud rate is the number of symbols transmitted in one second. In many 
computer systems, one symbol can represent one bit (zero or one) and so the baud rate 
and the bit rate are equal. 

BCD: Binary Coded Decimal. In this format, two four-bit codes are stored in a single 
eight-bit byte. Each of these four-bit codes can take on any of ten values from 0x0 
through 0x9. Values from Oxa through Oxf are forbidden. The interpretation of these 
four-bit codes is that they represent the decimal digits from 0 through 9. Thus, a single 
eight-bit byte can represent decimal numbers from 0 through 99. This format is the 
only one used by the National Semiconductor MM58167A real time clock. 

Bubble Memory: This is a form of integrated circuit memory which uses magnetic 
domains for storing information. These domains look like bubbles when viewed under 
a microscope, hence the name. Applying magnetic fields to the bubbles causes them 
to move about, permitting the information they represent to be stored and retrieved. 
From the standpoint of a user, they generally have two chief characteristics: 

1. The data are stored in a combination of random and sequential methods. Thus 
groups of data can be accessed randomly, but the elements of the group must be 
accessed sequentially. This is analogous to the way a disk storage device oper- 
ates. It accesses tracks directly, by moving its read-write head radially over the 
disk's surface to one of a set of concentric circles, called tracks. Once the head 
is positioned over the desired track, data is sequentially read from or written to 

it. 
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2. The data they contain are non-volatile. Removing power from them does not 
destroy their contents, provided this is done in a controlled manner. This is in 
contrast to the destruction of data in typical integrated circuit memories when 
power is removed from them. Those memories are non-volatile only if a battery- 
backup is available. The Intel bubble memory we are using will lose data if the 
temperature wanders outside the range [ - 20, + 75]°C [Ref. 1: Chapter 1, p.3). 

Digital-to-analog (D/A) converters: See the earlier discussion of analog-to-digital con- 
veners for some background on the difference between analog and digital signals. The 
purpose of the digital-to-analog converter is to convert a digital signal to a smoothly- 
varying continuous signal. Since the digital signal actually varies in jumps, it is not 
smooth to begin with. D A converters use low-pass filters to eliminate the high- 
frequency components represented by the sudden jumps of a digital signal. 

Dynamic: In the C programming language, most variables are dynamic. This means 
that they are created when a C function commences executing and are destroyed when 
that function completes executing. This is in contrast to the way static (q. v.) variables 
work. 

EEPROM: Electrically erasable, programmable ROM (q.v.). The contents of 

EEPROMs are not as easily modified as are the contents of RAMs. but they are 
non-volatile (they don't lose their contents when power is removed.) The contents of 
these memories can be erased electrically, but generally at a much slower rate than 
that at which they can be read. 

EPROM: Erasable, programmable ROM (^.v.). EPROMs can be erased for re-use 
if they are exposed to ultraviolet light for several minutes. It is usual to remove the 
integrated circuit from the circuit board to do this. EPROMs have a limited lifetime 
due to wear on the pins (unless zero-insertion-force sockets are used) and because their 
ability to be erased diminishes with age. 

Executable Program Module: The output of the link process ( q.v .) is a single file of 
machine code instructions. When placed in the computer's memory at the correct lo- 
cations (specified in advance), these instructions permit the computer to execute a 
program. 

FIFO: First-in, first-out. This term refers to a common data structure. One place 
this data structure is used is in the buffer on the bubble memory controller. That 
buffer server as an intermediate storage area between the bubble memory and the user. 
For example, when data are being read from the bubble memory by the user, they are 
retrieved from the bubble memory by the bubble memory controller and placed in the 
FIFO buffer. Concurrently, data are being removed from the buffer and sent to the 
user. The first characters of information to arrive in the buffer are the first to leave, 
hence the first in are the first out. 

Firmware: This term describes the computer programs which are stored in non- 

volatile memory, such as ROM (q.v.) 

Handshaking: When two devices communicate, they employ a protocol which speci- 
fies which device does what, when. This protocol is referred to as “handshaking”. 

Hexadecimal: Numbers to the base 16. It is customary to use the usual digits (0-9) 
as well as the letters ‘A’ (or ‘a’) through ‘F’ (or T), for the 16 distinct symbols required 
in this system. The C programming language by convention uses the prefix ; 0X’ (or 
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“Ox ) to make it clear that the appended characters represent a hexadecimal quantitv. 
For example. 

2a 16 = 0x2a = 2 16 x 16 1 + a 16 x 16° = 2 x 16 1 + 10 x 16° = 42. 

Input/Output space: The Z-SO and the essentially similar NSC800 provide a separate 
set of addresses for input and output devices. Certain instructions are reserved for 
these addresses, which can run from 0x00 through Oxff. They do not interfere with the 
corresponding memory address space ( q.v .) 

I/O: Input or output. 

I/O Space: See Input/Output Space. 

Latch up: A comparator will ordinarily produce a high voltage when the non- 

inverting input receives a higher voltage than that present on the inverting input. 
Similarly, it will ordinarily produce a low voltage when the non-inverting input re- 
ceives a lower voltage than that present on the inverting input. Some comparators 
are susceptible to the phenomenon called “‘latch up”. ^This entails a failure of the 
comparator to change its output according to the usual rules. Instead, the output 
signal will remain stuck at one value without regard to changes at the input. This 
feature is highly undesirable, as it means that the comparator is no longer performing 
as it should. 

Library: The output of the compilation or assembly steps is an object module. Se- 
veral of these can be stored in a library for convenience. During the link process, the 
linker can look in the modules stored in the library for definitions of objects whose 
names it does not recognize. The alternative to putting modules in a library is to 
specify them individually to the linker, which is somewhat less convenient. 

Linker: The linker is responsible for combining the object modules which comprise 
a complete program, and placing them in suitable memory locations. Object modules 
may include references to other modules or identifiers defined within other modules. 
These references must ultimately be resolved to memory addresses within the com- 
puter which will run the executable program. It is the job of the linker to perform this 
address resolution. To link a program is to request the linker to construct an execut- 
able program, and resolve all unknown addresses. The object modules may be ob- 
tained by the linker from either of two sources: from a library or from individual files 
containing only one module each. The output from the linker is a single file contain- 
ing an executable program module {q.v.) 

Memory address space: The Z-80 and the essentially similar NSC800 permit address- 
ing memory with addresses in the range 0x0000 through OxfiTf. Most instructions 
which use addresses, including stack instructions which do not explicitly address 
memory, use this space. There is another space of addresses called the input output 
space {q.v.) 

Module: In the C programming language, many functions may be grouped together 
in a single file of source code. These are considered to comprise a single module, for 
they are compiled as a unit and the resultant object code is stored in a single file, an 
object module f q.v.). Similar remarks hold when the source code consists of assembly 
language instructions, rather than instructions in the C programming language. In- 
deed. this concept is applicable irrespective of the programming language used to cre- 
ate the executable program. There are several advantages to building modules in this 
fashion. Chief among them is the separation of sections of a program according to 
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their functional characteristics. This permits testing one module independent of test- 
ing any other module. It also facilitates the use of fully debugged programs for other 
applications at a later date. 

Modulo: Consider a number .v and another number m. called a modulus. The number 
.v taken modulo m is written x mod m and it is defined to be the least positive number 
n such that x = kx m + n for some integer k. As an example, 5 mod 6 = 5 because 
0 x 6 + 5 = 5. Similarly, 9 mod 6=3 because 9 = 1 x 6 + 3, and -2 mod 6 = 4 since 
-2 = -1 x 6 + 4. Although we can also write -2 = -2 x 6 4- 10, -2 mod 6 ^ 10 be- 
cause 10 is not the least positive number which can be found to satisfy the equation. 

Nibble: A nibble is a half byte. This is a typical example of humor in the computer 
business. 

NSC810A: An integrated circuit from National Semiconductor which includes two 
eight-bit ports, one six-bit port, 128 eight-bit words of RAM (< 7 -v.) and two 16-bit bi- 
nary timers. 

Object Module: An almost-executable computer program. The reason it is not fully 
executable is that not all addresses within it have been resolved yet. nor has the linker 
established what addresses should be assigned to relocatable programs. Assemblers 
and compilers produce object modules. Linkers convert them into executable form 
by resolving the unresolved addresses and assigning all relocatable code to its final 
location. 

Parametric Registers: The Intel BPK 5V75A Four-Megabit Bubble Memory includes 
five parametric registers which must be loaded prior to attempting to perform input 
from or output to the bubble memory. Two of the five comprise the block length 
register, which defines both the number of bytes contained in a page of bubble mem- 
ory (c.g., 64), and the number of pages to be transferred from bubble memory to the 
bubble memory port or vice versa at a time. Two more specify at which of the 8,192 
pages in the bubble memory to start the transfer of data. The last, the “enable” reg- 
ister, primarily defines whether operation is to be interrupt-driven or not. 

Project G-313: This is the designation of the NASA project comprising the Vibro- 
acoustic Experiment. 

PROM: Programmable ROM (q.v.) These ROMs can be written to once by the user, 
but once written, their contents can never be modified. 

Quotation Marks: In C, double quotation marks (" ") are used to enclose character 
strings. Internally, the C compiler always places an ASCII NUL character (its 
hexadecimal representation is 0x00) at the end of a string. Single quotation marks 
(' ') are used to enclose a single character. Internally, the C compiler does not append 
an ASCII 0x00 to a single character. 

RAM: Random access memory'. This refers primarily to memory which can be writ- 
ten to and read from repeatedly. It commonly is volatile, i.e., its contents are de- 
stroyed when power is removed. 

ROM: Read-only memory’. This term is a bit of a misnomer. Obviously a memory 
which can never be written to would be of little value. Generally, it is much more 
difficult to modify the contents of a ROM than it is to modify the contents of a RAM. 
ROMs come in several varieties: 



xviii 



1. A mask- programmed ROM receives its data at the factory according to a 
customer’s specification when it is manufactured. 

2. A PROM {q.v.) is programmed once by the user. 

3. An EPROM (q.v.) can be programmed repeatedly, but must be erased by ultra- 
violet light between uses. 

4. An EEPROM {q.v.) also can be programmed repeatedly, but it can be erased 
electrically. 

RS-232C Serial Interface: This interface is also known as the EIA standard interface 
It was developed in 1969 by the Electronic Industries Association in conjunction with 
the Bell system, as well as independent manufacturers of computers and modems. 
Data are transmitted serially using two voltage levels. + Y„ represents a binary 0: 
- V ff represents a binary 1. 

The voltage V, can lie within the range [3.25]V. While the RS-232C defines the 
electrical characteristics of the interface, the functional description of the interchange 
circuits, and lists standard applications, it is silent on the subject of physical connec- 
tors. L'suallv. however. DB-25 connectors having 25 pins are used. The tables in 
APPENDIX I. RS-232C INTERFACE PIN CONNECTIONS on page 224 show 
the pin connections for the RS-232C interface. [Ref. 2: p. 6S3] 

SSDR: Solid State Data Recorder. This device stores audio data in magnetic bubble 
memories. It accepts commands analogous to those selected by pushing a button on 
a conventional, reel-to-reel tape recorder. For example, the commands PLAY and 
RECORD exist. However, access to the data can be random. 

Static: In C. most variables are dynamic {q.v.) They can be made static by the inclu- 

sion of this keyword in their declarations. This causes them to become permanent. 
They are not then created when the function in which they are declared starts to exe- 
cute. They are created at the time of compilation. They do not lose their contents 
when that function’s operation ends. The contents of the storage locations assigned 
to them remain intact until the next time that function tries to access that variable. 

CART (Universal Asynchronous Receiver-Transmitter): A common integrated circuit 
which provides asynchronous communications between two hardware devices. We use 
it to implement an RS-232C serial interface between the controller hardware and a 
terminal. 

Volatile Memory Storage: Conventional RAM (q.v.) loses its contents when power is 
removed. This property is called volatility. By contrast, magnetic core and bubble 
memories are non-volatile. For that matter, printed pages are also non-volatile 
memories. 

Voltage Controlled Oscillator (VCO): The VCO operates a loudspeaker in the exper- 
iment during the sweep phase. The frequencies are increased incrementally between 
35 Hz and 785 Hz in 1 Hz increments. 
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I. INTRODUCTION 



Since it began flying into space in April, 1981 the Space Shuttle has made it much 
easier to get payloads into space. Although the shuttle was grounded because of the 
tragic explosion of the Challenger on January 28, 1986, flights resumed in October, 1988. 

A. GET AWAY SPECIAL (GAS) 

In 1976 the National Aeronautics and Space Administration (NASA) established the 
Get Away Special (GAS) program [Ref. 3: p.ll]. The purpose of this program is to 
permit individual experimenters to have room on the Space Shuttle for their experiments, 
provided there is no undue interference with the rest of the mission as a result. To pre- 
clude such interference. N ASA therefore imposes a number of constraints on these ex- 
periments. Among these are 

1. They must contain their own power source, heating, data handling facilities, and 
so on [Ref. 4: p.S]. 

2. No more than three external switches may be provided for operation by crew 
members. Of these, one must be devoted to removing all power from the pavload 
[Ref. 4: p. 2S]. 

The Space Shuttle is subject to powerful acoustic vibrations during launch. In the 
past, minor breakage of crystals and circuit boards has resulted [Ref. 3: p.ll]. It is 
thought that the vibrations are responsible for this damage, and that some regions of the 
cargo bay are more susceptible to damage than others. Acoustical analysis of the sound 
waves which cause these vibrations could reveal where the best and worst locations are. 

Several early GAS experiments carried conventional reel-to-reel tape recorders and 
were intended to record the acoustic waves in the cargo bay for subsequent analysis. 
However, the analysis was flawed for several reasons [Ref. 5: p. 15]. Among these were: 

1. The microphones were mounted close to the bulkhead of the cargo bay, within a 
partial enclosure. Thus the data might have been erroneous. 

2. The data recorded by the microphone may have been contaminated by interaction 
between the microphone and its isolation system. 

3. The acoustical waves in the forward third of the cargo bay were not recorded. 

Furthermore, astronauts were too busy at launch time personally to initiate the exper- 
iments. Instead, the experiments included circuitry to detect the roar of the main engines 
and trigger the commencement of the experiment [Ref. 6: p. 11]. There is good reason 
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to doubt the validity of the analysis of acoustic waves whose collection was itself trig- 
gered by the occurrence of those same waves. As a result of all these factors, the anal- 
ysis so far has been ambiguous. 

B. THE VIBRO-ACOUSTIC EXPERIMENT 

The Space Systems Academic Group at the Naval Postgraduate School plans to 
conduct an experiment as NASA project G-313 to obtain improved acoustical meas- 
urements in the cargo bay of the Space Shuttle during launch. In the remainder of this 
thesis, we shall refer to this project as the Vibro-acoustic Experiment. The reader is re- 
ferred to [Ref. 7] for a general overview of the experiment. 

The purpose of this thesis is to describe the software and some of the hardware 
which controls the Vibro-acoustic Experiment. At times this thesis will merely describe 
the work we have done. At other times, it will prescribe what to do to achieve various 
ends. Thus it will serve not merely as documentation of what has been done, but it will 
also serve as a manual for those who might wish to elaborate on this earlier work. 

The majority of the work performed by the author had to do merely with the control 
of the experiment. However, the matched filter (described in Chapter 111. THE 
MATCHED FILTER on page 21) was redesigned by the author and is completely de- 
scribed in this thesis. 

A great deal of the hardware and software created to control the Vibro-acoustic 
experiment is very general in nature, and would apply without change to other exper- 
iments. We will attempt to indicate which components have general applicability. The 
hope is that future applications will benefit from this approach, and will be spared the 
need to build and program a controller from scratch. More information on the 
general-purpose controller hardware we use in the Vibro-acoustic Experiment can be 
found in Chapter II. CONTROL HARDWARE on page 10. The software is described 
in general terms in Chapter IV. DESIGN OF THE CONTROL SOFTWARE on page 
43. 

C. DIFFERENCES FROM EARLIER EFFORTS 

Like earlier experiments, this one is housed in a GAS canister. It differs from them, 
however, in several key respects. 

1. Isolation of Microphones 

The experiment uses microphones housed in a mounting designed at the Naval 
Postgraduate School to isolate them from vibration. This is intended to reduce the 
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contamination of the recorded acoustical waves by structural vibrations. This micro- 
phone arrangement is described in Stehle [Ref. 5]. 

2. Solid State Data Recorder (SSDR) Using Bubble Memory 

Conventional reel-to-reel tape recorders are supplanted by a recorder using 
magnetic bubble storage. This recorder was also designed at the Naval Postgraduate 
School and has the following advantages over conventional recorders. 

1. It contains no moving parts, so is less prone to mechanical failure. 

2. It permits random access to data, not possible with tape. While such a capability 
is commonplace with disk storage, disks do suffer from mechanical breakdown. 
Also, they are vulnerable to errors when external accelerations occur, as they do 
during a launch. This is less problematic in the case of bubble memories. 

3. Bubble memory is non-volatile, that is, its contents are not destroyed when power 
is removed. Thus battery power is not required to keep the stored data available. 
Slightly offsetting this advantage is the fact that power must be removed in a con- 
trolled fashion, and specified temperature limits must be maintained. 

The magnetic bubble recorder is described in Frey [Ref. S]. 

3. Microprocessor Control of the Experiment 

To operate the experiment, another group at the Naval Postgraduate School 
built a single-board, microprocessor-based controller. This general-purpose controller 
uses a National Semiconductor NSCSOO microprocessor (roughly equivalent in function 
to a Zilog Z-SO). This controller, as it was originally conceived, is described in Wallin 
[Ref. 3J. From a programmer's standpoint, the controller has the characteristics de- 
scribed in Chapter 11. Section A. Standard Controller on page 10. 

The controller will be responsible for: 

1. activating all subsystems at the appropriate time; 

2. monitoring execution of the experiment; 

3. keeping a log of significant events and the dates and times at which they occurred. 
This log is stored in the controller’s bubble memory module; 

4. recording temperature and voltage readings while the shuttle is in space; and 

5. ensuring that the bubble memories do not get too cold. This is done by 
intermittentlv operating the heater subsystem to maintain a temperature above 
10°C . [Ref. 1: p. 3] 

In addition to the obvious functions called for in controlling the experiment, the soft- 
ware also contains a menu-driven diagnostic subsystem to provide for testing on the 
ground. ^See APPENDIX B. CHOICE OF A SOFTWARE DEVELOPMENT SYS- 
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TEM on page 83 for a general description of the several software development systems 
we have used.) 

D. PROCEDURAL OUTLINE OF THE V1BRO-ACOUST1C EXPERIMENT 

In this section we sketch an outline of the operation of the Vibro-acoustic Exper- 
iment. The flowcharts in Chapter IV, Section 2. Performing the Experiment on page 
46 show the procedure which the experiment follows. A synopsis of this procedure is 
provided here.l The experiment begins to operate when the ground crew or astronauts 
turn on a switch in the cabin, causing power to be applied to the GAS canister which 
houses the experiment. With power applied, the microprocessor comes to life. Its first 
task is to initialize the programmable hardware ports and timers. It then has to decide 
whether or not to perform the complete experiment or an abridged version of it. The 
need for such a decision will become apparent presently. For the moment we will con- 
fine our attention to the unabridged experiment. 

1. Sweep Phase 

Once the cargo bay has been loaded, the ground crew will activate the exper- 
iment for about an hour to let it perform the sweep phase. During this phase, the cargo 
bay is irradiated with a sequence of acoustic tones of known frequencies and the acoustic 
response of the enclosure is recorded by the Solid State Digital Recorder (SSDR). After 
the mission, analyzing this data [Ref. 9] and comparing it to the echoes recorded during 
launch will reveal the locations of the regions most and least prone to damage from vi- 
bration. This phase is the longest, and lasts 13 minutes. 

2. Detection of the Auxiliary Power Units (APUs) 

The Space Shuttle’s Auxiliary Power Units (APUs) are jet turbines used to op- 
erate control surfaces during launch and recovery of the shuttle. The APUs start to 
operate around five minutes before launch. Because they emit a characteristic frequency 
at 600 Hz, we can use a matched filter to detect their acoustic signature 
[Ref. 6: pp. 15-18]. When the matched filter detects this signal, it knows that launch 
is imminent, and it is time to start recording the sounds which occur prior to launch. 
Thus we will record the sounds before, during, and after launch. By not waiting for the 
roar of the main rocket engines before starting to record the ambient noise, we will avoid 
the problem mentioned in Chapter I, Section A. Get Away Special (GAS) on page 1. 
The data collected by this means should be much more accurate. 



1 See Chapter IV, Section B. Operation of the Vibro-acoustic Experiment on page 45 for 
complete details. 
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Since there exists the possibility that for some reason the matched filter will fail 
to detect the APL's, the experiment includes two backup systems. 

1. The Vibration-activated Launch Detector will detect the vibrations associated with 
launch. 

2. A second backup system will use two barometric pressure switches to detect the 
drop in atmospheric pressure which occurs as the Space Shuttle rises. These 
switches will be placed in a redundant, parallel configuration. Thus, if either one 
or both of them work, the drop in barometric pressure will be detected. 

Neither of these systems can detect operation of the APL's. However, if either one 
should detect a launch, the control program stops waiting for the APUs to come on and 
switches immediately to the launch phase. 

If the matched filter successfully detects the APUs but the Vibration-activated 
Launch Detector fails to detect launch, the barometric sensor will cause the experiment 
to switch to launch phase, albeit a little late. 

It would be unfortunate if the matched filter failed to detect the APUs. for then 
one of the primary advantages of the Vibro-acoustic Experiment over earlier efforts to 
record acoustical noise in the Space Shuttle would disappear. It would be doubly un- 
fortunate if neither the matched filter nor the vibration detection subsystem workeJ. for 
then no data would be recorded until well after launch. If any one of the three systems 
works as designed, then the experiment will acquire at least some data. 

3. Scroll Phase 

If the matched filter detects the APUs, the control program will place the Solid 
State Data Recorder (SSDR) into scroll mode. In this mode, the SSDR uses a subset 
of its bubble memory for recording the ambient noise prior to launch. The fraction of 
memory dedicated to this purpose permits at most 1 10 seconds of recording time. Once 
this memory is used up. the SSDR will start re-using it from the beginning.- As a result 
of this mode of operation, roughly two minutes of pre-launch noise will be recorded, 
along with the noise of the ignition of the main engines. 

4. Launch Phase 

Either the vibration detection subsystem or the barometric sensors can trigger 
detection of a launch. When a launch is detected, the control program puts the SSDR 
into launch mode. The purpose of this mode is to record the noise after the launch be- 
gins. In launch mode, enough memory is dedicated to permit about two minutes of 

2 In effect, the SSDR is writing onto a continuous, looped scroll, hence the name of this mode 
of operation. 
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ambient noise to be recorded.3 Once this memory is exhausted, the SSDR will signal the 
control program that it has finished operations. 

5. Post-launch Operations 

After the SSDR has signalled completion, the Vibro-acoustic Experiment has 
finished gathering all the acoustical data it needs. The controller will continue, however, 
to monitor and record temperature in the GAS canister and record this information in 
its own bubble memory module. It will also monitor and record voltage levels of each 
of three power supply batteries. If these should fall below 8.5V, it will halt. This pre- 
vents loss of data in the bubble memory due to insufficient voltage and current levels. 

The basis for choosing 8.5V follows. Each individual cell is rated for 2.0V. 
There are five of these cells in the 10 V stack which powers the bubble memory. If any 
cell drops to 1.81V or below, it is considered to be below the operating threshold. Five 
such cells generate 9.05V. The bubble memory itself can operate on as little as 5 V. 
We know that the batteries are losing power when the voltage falls below 8.5 V, but we 
still have a margin of 3.5 V above the voltage required to operate the bubble memory. 
(The margin is reduced slightly due to the presence of 5 V voltage regulators in the cir- 
cuit. but it is still ample.) It is therefore reasonable to halt operations if the voltage falls 
below 8.5V . 

Also, if the temperature of the bubble memory falls below 10°C, it is below the 
minimum operating temperature, and we will suspend operation of the bubble memory 
until the temperature returns to 10°C once more. Likewise, if the temperature should 
rise above 55°C, it is above the maximum operating temperature, and bubble memory 
operations will be suspended until the temperature drops within the operating range 
again.-* [Ref. 1: Chapter 1. p. 3] 

6. Abridged Experiment 

NASA has balked at the idea of our performing the sweep phase. They are 
concerned over the possibility that the loud sounds generated during the sweep might 
damage other payloads or frighten technicians. They also are reluctant to remove per- 

3 Since the shuttle's cargo bay is not pressurized, the air will leak out as the outside pressure 
drops. After two minutes, there will be no appreciable atmosphere left inside the cargo bay, and 
all sound will have ceased. 

4 These checks are only performed during the post-launch phase, which begins within two or 
three minutes from the time of launch. It is unlikely that NASA would launch the shuttle if the 
outside temperature were below 10 = C, and we do not anticipate that the temperature will fall 
appreciably within the first three minutes of flight. 
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sonnel from the vicinity of the shuttle during that phase. They are equally reluctant to 
require those personnel to wear hearing protection during the sweep. 

Those arguments seem specious to us. It strikes us as unlikely that damage to 
equipment might result from the sweep but not from the rocket motor noise during lift 
ofT. \\ e cannot see the reason why personnel whose hearing might be damaged during 
the sweep cannot wear hearing protection. While we can still perform an analysis of the 
recorded data without first doing a sweep, it is likely to produce less useful results. 

We have decided to proceed as we wanted to originally, that is, to design an 
experiment which would do everything we want. We have added an additional decision 
point to permit the abridged experiment to take place. This shortened experiment would 
simply turn on the recorder when the APL's were detected or when launch occurred, and 
we would hope for the best. There would be no sweep, no scroll, and no launch phases: 
there would only be a record phase, once the APL s or a launch were detected. 

Once NASA sees that the abridged experiment works, that the analysis provides 
good results, and that permitting the unabridged experiment will yield even better data, 
we hope that they will relent and permit us to fly the experiment again in the unabridged 
mode. 

E. IRREGULARITIES 

What happens if the power fails temporarily and then is restored? This might hap- 
pen if the power switch is inadvertently switched off by the ground or flight crew, or 
through some equipment malfunction. Upon the restoration of power, the micro- 
processor must decide where in its procedure to resume execution. There are several 
cases to consider. 

1. The sweep phase has never been initiated, nor has a launch occurred. The correct 
action is to start at the beginning. 

2. The sweep phase has been initiated. It is not known whether or not it ever was 
completed, but a launch has not occurred. The correct action is to skip the sweep 
phase and wait for some indication of a launch. The sweep creates a very loud 
noise which would be hazardous to ground personnel if it were permitted to occur 
at other than a scheduled time. Since this time is not known at present, and never 
is firmly enough known in advance to be programmed into the computer, we can- 
not risk running the sweep phase if it is interrupted by a power fault. 

3. The sweep phase has been initiated (and presumably completed), the APUs are on, 
but no indications of a launch are present. The correct action is to enter scroll 
mode. If it was already in progress when the power fault occurred, it will be re- 
started. This is all right, since no vital information will be lost by this procedure. 

4. The sweep phase has been initiated (and presumably completed) and conditions of 
a launch are present but the barometric switch has never been tripped. The correct 
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action is to assume we are just beginning a launch and to initiate launch mode. 
This creates a risk that recordings of the moment of launch would be lost if a power 
fault occurred between the moment of launch and the triggering of the barometric 
switch as the spacecraft ascends. There is no obvious way entirely to eliminate this 
risk. 

5. The sweep phase was initiated (and presumably completed) and the barometric 
switches were activated at some earlier point. This implies that the power fault 
took place after the activation of the barometric switches, that is, after launch. The 
correct action is to assume that launch data was successfully recorded and to initi- 
ate the post-launch monitoring operations. 

F. OTHER APPLICATIONS 

The controller hardware is sufficiently powerful that it could easily provide control 
for other applications. In particular, many spaceborne applications could be operated 
by it. 

In the course of developing the control software, we had to create support routines 
to take care of a great many mundane functions. In computers with operating systems, 
these functions are typically provided by the operating system. The user has merely to 
know about them and use them. 

The controller we use has no operating system, so we had to create many low-level 
functions, e.g., one which converts a hexadecimal number to a character string repres- 
enting that number. 

At a higher level, we wrote subroutines to display text on a terminal, operate a 
bubble memory, operate a real-time clock, and control various external devices through 
the 44 input and output lines provided with the controller. 

By using the low-level subroutines, and by organizing an application's software in 
a similar manner, much of the most tedious and uninspiring work entailed in producing 
a control program for this controller hardware could be avoided. This would leave more 
time to devote to the real purpose of the application. In an environment with few people 
available to do the work, such economy is very attractive. 

Another consideration is the lack of a need to use assembly language in program- 
ming the controller. In the very few places where it was required, we used it. Along 
with the large collection of C language subroutines of general applicability, the routines 
we have already provided in assembly language should suffice for almost all run-of-the- 
mill work. 

In one area we were ourselves compelled to abandon the use of C language source 
code and switch to assembly language code. We initially hoped that only the start-up 
code, the input routine, the output routine and the software delay routine would require 



the use of assembly code. We assumed we could input from and output to the bubble 
memory using compiled C language source code. 

This assumption turned out to be incorrect. We needed a data transfer rate of 
16,000 bytes per second [Ref. 1: Chapter l, p. 3], but could only attain around 3,000 
bytes per second. Consequently, we had to replace a small section of C code with as- 
sembly language source code. Even this was necessary only because we used a prototype 
bubble memory board with a buffer whose size was inadequate to handle data transfers. 
While this buffer provided only 40 characters of space, we needed 64. 

When speed becomes paramount, assembly code may be necessary, since it can be 
tailored to the job at hand and so produce very efficient programs. 5 For many applica- 
tions, however, speed is not critical. It ordinarily is foolish to waste time achieving in 
assembly language what can be done much more quickly using a high-level language. 
Only if you cannot achieve the desired performance with a high-level language, must you 
use assembly language. 

Irrespective of whether some portion of an application does or does not demand 
efficient code (written in assembly language), for most applications the majority of the 
code can be written in a high-level language such as C. Many applications, too. need 
no more facilities than those provided in the Yibro-acoustic Experiment. In such cases, 
building on the work presented in this thesis has very clear advantages. 



5 Nonetheless, some optimizing compilers surpass quite competent assembly language pro- 
grammers in efficiency. 
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II. CONTROL HARDWARE 



The controller we use in the Vibro-acoustic Experiment is based on the NSC800 
microprocessor. For all practical purposes, this is functionally equivalent to the Zilog 
Z-806 [Ref. 10]. Figure 1 on page 11 is a block diagram showing the major components 
of the system. To the left of the microprocessor appear those peripherals which ordi- 
narily fall under the control of the standard controller. We discuss these peripherals and 
their capabilities in Section A. Standard Controller below. One can connect an assort- 
ment of devices to the 44 input and output lines available on it. Other applications than 
the Vibro-acoustic experiment could use this bare-bones controller for their own pur- 
poses. 

To the right of the microprocessor appear those peripherals which are peculiar to 
the Vibro-acoustic Experiment. We discuss these peripherals and their capabilities in 
Section B. Additional Controller Hardware on page 14 below. 

A. STANDARD CONTROLLER 
1. NSC810A RAM-I/O-Timers 

Two NSCS10A RAM-I O-Timer units provide four eight-bit ports and two six- 
bit ports. These provide 44 bits of input and output capability. There also are two 
timers on each device. One of each pair is completely independent of the data ports; the 
other, if used, reduces the number of available pins in the six-bit port to three. We have 
configured the system such that one of the latter kind of timer is unavailable, since we 
have dedicated the data lines with which it interferes to other purposes. The two timers 
which do not conflict with any data lines at all are dedicated to providing: 

1. A 153.6 kHz signal to the IM6402 Universal Asynchronous Receiver Transmitter 
(L'ART) where it is divided by 16 to yield a %00 BAUD clock for serial data 
transmission. 

2. A 614.4 kHz clock which is provided to the ADC0816 Analog-to-Digital Converter. 

Thus one of the four timers is available for other uses. 

We shall hereafter refer to the two devices as NSC810A #1 and XSC810A n 2 
respectively. The XSC810A reference manual [Ref. 11] refers to the eight-bit ports by 

6 The NSC800 includes several instructions not included with the Z-80. Since the Z-80 is the 
better-known device, we have not used any of the added instructions. 
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Figure 1. Block diagram of major components of the Vibro-acoustic Experiment. 



11 



the letters A and B, and to the six-bit port by the letter C. In the rest of this thesis, when 
we wish to distinguish between ports on NSC810A »1 and NSCS10A *?2, we shall ap- 
pend a subscript to the port's letter, e.g., A, is NSC810A #1, port A. 

NSC810A #1 uses port addresses 0x00 through 0x19.7 NSC810A #2 uses port 
addresses 0x20 through 0x39.8 

General information on programming the NSC810A can be found in [Ref. 11]. 
We present the specific manner in which these devices have been programmed for the 
Vibro-acoustic Experiment in Section A. Major Subroutines and Functions on page 
108. 

2. On-board Analog-to-digital Converter 

An eight-bit, 16-channel. National Semiconductor ADC0816 analog-to-digital 
(A D) converter permits the monitoring of voltages and temperatures at various points 
within the experiment. It can be mounted right on the microprocessor-based controller 
board. The device is connected starting at input output space address 0x80. Conversion 
of an analog input to a digital number is signalled to the control program by the exist- 
ence of a 1 in bit 3 of port C : . 

3. Bubble Memory Module for the Controller 

Devoted to the use of the controller board is a 512 KByte Intel BPK 5Y75A 
Four-Megabit Bubble Memory Prototype Kit. The control program will maintain a log 
in this memory of all actions it takes during the experiment. The information will in- 
clude a code signifying the action taken, the time and date of that action, and the current 
temperature and voltage readings. 

After launch, the Vibro-acoustic Experiment is over. The control program then 
uses the log solely for the purpose of recording temperatures and voltages. 

Port address 0x40 provides access to the bubble memory. There are 8192 pages 
of 64 bytes per page. Pages of the bubble memory can be specified at random by num- 



7 The term “port” is somewhat ambiguous. The NSC810A reference manual (Ref. 11] refers 
to a collection of pins within an NSC810A integrated circuit as a port. This particular device 
contains three ports: A, B and C. In common parlance, however, the term port refers to a par- 
ticular address in the input -output address space (1,0 space) of the Z-80. This space spans ad- 
dresses from 0x00 through Oxff. We might say, for example, that we perform an input operation 
from port Oxla. This is equivalent to saving we input a b\te (character) from I O space address 
Oxla. We shall seldom attempt explicitly to state which use is intended. The meaning may gener- 
ally be ascertained from the context. 

8 See the discussion on hexadecimal notation in the Glossary. 
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bers from 0 through S 19 1 . Port address 0x41 provides control information for this 
memory device. 

The bubble memory ’s reset line should be brought low by placing a 0 in bit 5 
of port C 2 before applying power to or removing power from the bubble memory. It is 
important to wait at least 50 ms after applying power before attempting to initialize the 
bubble memory [Ref. 1: Chapter 4, p. 3]. 

Power can then be applied to the bubble memory by putting a 1 in bit 4 of port 
C 2 . Putting a 0 there removes power. 

Details of the operation of this memory' and the meaning of the control byte 
information are in [Ref. 1]. We describe the manner in which we have programmed the 
bubble memory to support the Vibro-acoustic Experiment in Section A. Major Sub- 
routines and Functions on page 108. 

4. Real Time Clock 

A National Semiconductor MM5S167A real time clock makes it possible to re- 
cord in the log of events the dates and times of all actions taken. We also use this device 
to limit the amount of time the control program waits for various events to occur. If the 
event does not occur for some reason, the control program decides to stop waiting. 

For example, once the Auxiliary Power Units (APUs) are detected, there is a 
window of about seven minutes in length. If launch docs not occur within this window, 
the launch will be scrubbed since the APUs will no longer have sufficient fuel. We can 
therefore regard the experiment as having been aborted if this amount of time passes 
without a launch. We use the real-time clock to detect the passage of this period of time. 

5. RS-232C Serial Input/Output Port 

An RS-232C interface provides communication with a serial device such as a 
terminal. This makes it feasible to monitor and control the system on the ground. By 
connecting a terminal to this interface, the user has access to an extensive, menu-driven 
diagnostic subsystem. (This menu subsystem is dormant if there is no terminal at- 
tached.) No intelligence currently is required on the part of the terminal: it is purely a 
display device.9 Port address OxeO holds control information to and from the serial de- 
vice. Port address OxcO funnels data either to or from the device. Table 1 on page 14 
shows the use of the bits of the control port. 

9 Mr. David Rigmaiden of the Space Systems Academic Group at the Naval Postgraduate 
School has proposed encoding the diagnostic messages and using an intelligent terminal to display 
the corresponding human-readable messages. However, no one has yet done any work on this. 
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If there is a terminal connected to the RS-232C Serial port at addresses Oxco 
and OxeO. then bit 3 of port C, will be a I. This permits the control program to distin- 
guish diagnostic operation on the ground (when there will be a terminal attached) from 
actual performance of the experiment (when there will not be a terminal attached.) As 
can be seen in Figure 1 on page 11, the Vibro-acoustic Experiment will not use a ter- 
minal when it is in space. 

Table 1. ASSIGNMENT OF BITS IN THE RS-232C SERIAL INTERFACE 



PORT: This port uses address OxOe for control information and 0x0c for 
data. 



Bit 


Direction of 
Data Flow 


Meaning 


0 


Input 


0 if the attached device can accept output infor- 
mation. 1 otherwise. 


1 


Input 


1 if the attached device has data available. 0 oth- 
erwise. 



B. ADDITIONAL CONTROLLER HARDWARE 

The Vibro-acoustic Experiment uses several subsystems which are not a part of the 
standard controller. Most of these subsystems appear to the right of the microprocessor 
in the block diagram in Figure 1 on page 11. The only one which does not is the Power 
Control Subsystem, which is drawn below the microprocessor. These subsystems have 
the following functions: 

1. Analog-to-digital Converter Subsystems 

Three A D converters convert the analog acoustical signal detected by a set of 
three microphones into the digital format required by the Solid State Data Recorder 
(SSDR). The design and operation of the SSDR is provided in [Ref. 9]. 

2. Solid State Data Recorder (SSDR) 

The SSDR is comparable in function to a conventional reel-to-reel tape re- 
corder. Unlike a standard tape recorder, it is not limited to sequential operation; it can 
access data randomly. The operation of the SSDR is more fully described in [Ref. 8]. 

To issue a command to the SSDR, place its code in port A[ on NSCS10A #1, 
located at I O space addresses 0x00 through 0x19. The SSDR will place a status code 
reflecting its operating state in port A 2 . Table 4 on page 17 defines the command codes 
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Table 2. BIT ASSIGNMENTS FOR READING POWER SUBSYSTEM RELAY 



SETTINGS: The position of relays may be determined by reading port 

B, (on NSC810A =2), which is located at I O space addresses 0x20 through 
0x39. 



Bit 


Direction 
of Data 
Flow 


Value 


Meaning 




Not used. 


1 


Input 


1 


The Solid State Data Recorder (SSDR) is on 




0 


The SSDR is off. 


-> 


Input 


1 


The Voltage Controlled Oscillator (VCO) is oil. 




0 


It is off. 


3 


Input 


l 


The Analog to Digital Conversion (A D) cir- 
cuit is on. 




0 


It is off. 


4 


Input 


l 


The Matched Filter . Vibration-activated 
Launch detector, and Barometric Pressure 
Switches are on. 






0 


It is oil 




Input 


1 


The heater circuit is on. 




0 


It is off. 



for the SSDR. Table 5 on page 17 defines the status codes the SSDR can return to the 
control program. The following SSDR commands are of particular note: 

Sneep Record 12.5 minutes of pre-determined frequencies emitted by the Voltage 
Controlled Oscillator (VCO) prior to launch. 

Scroll Record up to 55 seconds of ambient noise during the five minutes or so 
between the time the Auxiliary Power Units (APUs) come on and the time 
of launch. In this mode, the SSDR will continually re-use the same portion 
of SSDR memory. There are two sections of memory devoted to this pur- 
pose, and use alternates between them. Each can hold up to 55 seconds of 
ambient noise. When the SSDR is commanded to enter launch mode, the 
memory section currently in use will be filled and then the SSDR will switch 
over to that section of memory devoted to recording post-launch noise. 

Launch The experiment’s control program orders the SSDR to enter launch mode 
as soon as the Space Shuttle launches. This mode lasts for two minutes, 
which is about the time it takes to evacuate the air from inside the 
shuttle's cargo bay. During this mode, the SSDR records ambient noise. 
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Table 3. BIT ASSIGNMENTS FOR CONTROLLING POWER SUBSYSTEM 
RELAYS: Relays may be controlled through port B, (on NSCSIOA «1), 

which is located at 10 space addresses 0x00 through 0x19. 



Bit 


Direction 
of Data 
Flow 


Value 


Meaning 


0 


Output 


1 


Turn on the relays specified in the other bit 
positions. 


0 


Turn off the relays specified in the other bit 
positions. 




Output 


1 


Operate the Solid State Data Recorder 
(SSDR). 




0 


Do not operate the Solid State Data Recorder 
(SSDR). 


2 


Output 


1 


Operate the Voltaae Controlled Oscillator 
(YCO). 


0 


Do not operate the Voltaae Controlled 
Oscillator (VCO). 




Output 


1 


Operate the Analog to Digital Conversion 
(A D) circuit. 




0 


Do not operate the Analog to Digital Conver- 
sion (A D) circuit. 


4 


Output 


1 


Operate the Matched Filter (including 
accelerometer and barometric switch). 




0 


Do not operate the Matched Filter. 


5 


Output 


1 


Select the heater circuit. 


0 


Do not select it. 



As can be seen in the flowchart in Figure 22 on page 50, most of the experiment 
is devoted to the operation of the SSDR, that is, to placing it in the mode appropriate 
for the current phase of the Space Shuttle’s mission. 

3. Matched Filter 

As mentioned in Section 2. Detection of the Auxiliary Power Units (APUs) 
on page 4, a matched filter will detect the characteristic 600 Hz signature of the APUs. 
This device will place a 1 in bit 0 of port C, if a detection occurs. Normally it leaves a 
0 there. Table 6 on page 18 shows the uses of all the bits of Port C P The matched filter 
is described in Chapter III. THE MATCHED FILTER on page 21. 
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Table 4. SSDR COMMAND CODES: Commands are issued by writing them to 
port .-1, on NSCS10 «1. located at 1 O space addresses 0\Q0 through 0x19. 



Code 


Value 


Meaning 


STANDBY 


0x01 


Commands the SSDR to cease all operations and 
await further commands. 


SWEEP 


0x02 


Commands the SSDR to enter sweep mode. 
Enough memory is available for holding holding 
12.5 minutes of noise generated by the VCO. 


SCROLL 


0x04 


Commands the SSDR to enter scroll mode. 
Enough memory is available for holding 30 sec- 
onds of ambient noise. 


LAUNCH 


0x08 


Commands the SSDR to enter launch mode. 
Enough memory is available for holding two 
minutes of ambient noise. 


RECORD 


0x10 


Commands the SSDR to start recording noise. 
This is analagous to the RECORD button on 
conventional tape recorders. 


PLAYBACK 


0x20 


Commands the SSDR to play recorded data back. 
This mode is analogous to the PLAY button on 
conventional tape recorders. 



Table 5. SSDR STATUS CODES: Status codes may be obtained by reading them 

from port A 2 on NSCS10 =2. located at I O space addresses 0\20 through 
0x39. 



Code 


Value 


Meaning 


OPCOMP 


0x40 


Shows that the SSDR has completed the last 
command it received. 


NORMOP 


tlx SO 


Shows that the SSDR is operating normally. 



4. Voltage Controlled Oscillator (VCO) 

The purpose of the VCO is to irradiate the shuttle’s cargo bay with sound of a 
predetermined frequency during the sweep phase. This is done by applying power to a 
loudspeaker. The VCO is designed to step up in frequency from 35 Hz through 785 Hz 
in 1 Hz steps. By recording the echoes, subsequent analysis will permit a comparison 
of the acoustical response of the pure tone to that of the noise generated during launch. 

5. Vibration-activated Launch Detector 

This circuit is mounted on the same circuit board as the matched filter. Its 
purpose is to enable the control program to detect a launch, and so enable it to com- 
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Table 6. BIT ASSIGNMENTS IN PORT C, OF NSC810A #1 



Bit 


Direction 
of Data 
Flow 


Value 


Meaning 


0 


Input 


1 


Detection of the Auxiliary Power Units (APUs) 
has occurred. 


0 


Detection of the Auxiliary Power Units (APUs) 
has not occurred. 


1 


Input 


1 


The Vibration-activated Launch Detector has 
detected a launch. 


0 


The Vibration-activated Launch Detector has 
not detected a launch. 


2 


Input 


1 


One of the barometric pressure switches has 
detected a launch. 


0 


Neither barometric pressure switch has de- 
tected a launch. 


3 


Input 


1 


No terminal is connected to the port. 


0 


A terminal is connected to the RS-232C serial 
interface port. 


4 


Output 


1 


Order the power subsystem to change the 
states of the relays specified in the command 
at port B, 


0 


Do not change the states of the relays. 


5 


Not used. 



mand the Solid State Data Recorder to enter launch mode. It will set bit I of port Q 
high when it detects a launch (see Table 6 on page IS). Even if the matched filter never 
detects the APE's, detection of launch will still cause the control program to force the 
SSDR into launch mode. 

6. Barometric pressure switches 

On the same circuit board as the matched filter there are two barometric pres- 
sure switches connected in a redundant, parallel configuration. These switches serve as 
a backup for the Vibration-activated Launch Detector. Either one of them will place a 
high voltage in bit 2 of port C, (see Table 6) when pressure drops below 27.9 inches of 
mercury. This pressure corresponds to an altitude between 1500 feet and 2000 feet when 
the lowest barometric pressures on record at Cape Canaveral are present. In general, 
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Table 7, BIT ASSIGNMENTS IN PORT C 2 OF NSC810A #2 



Bit 


Direction 
of Data 
Flow 


Value 


Meaning 


0 


Output 


1 


Operate the heater subsystem. 


0 


Do not operate the heater subsystem. 


I 


Not used. 


2 


Not used. 


3 


Input 


1 


Analog to digital conversion is complete. This 
refers to the On-board A D Converter (see 
Figure 20 on page 48). 




0 


Analog to digital conversion is not yet com- 
plete. 




Output 


1 


Apply power to the bubble memory. 


4 


0 


Do not apply power to the bubble memory. 






1 


Do not apply a reset signal to the bubble 
memory. This is the normal setting. 


5 


Output 


0 


Apply a reset signal to the bubble memory. 
This must be done while power is applied to 
or removed from it. Once the power has been 
switched on or off. the reset line can be re- 
turned TO 0. 



the corresponding altitude will be somewhat higher than this since barometric pressures 
will generally not be at their lowest when NASA launches a Space Shuttle. 

7. Heater Circuit 

The purpose of the heaters is to maintain the temperature of the controller's 
bubble memory module at or above 10 C C during operation, and above — 20°C otherwise. 
To do this, there are heater strips attached to the bubble memory module. To turn on 
the heaters, the control program places a 1 in bit 0 of port C 2 . It puts a 0 there to turn 
them off. Insufficient power is available to heat all the bubble memories in the Solid 
State Data Recorder (SSDR). If the contents of the log are saved, however, it should 
at least be possible to ascertain the c-use of the loss of acoustic data in the SSDR. 

8. Power Control Subsystem 

Three batteries of dry cells, each powering a different bus, provide power to the 
experiment. Partly in order to conserve power, but also to permit isolation of subsys- 
tems if an overheat condition occurs, most subsystems receive power only when neces- 
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sary. The power subsystem includes a relay for each of these other subsystems. By 
writing appropriate commands to port B, we can turn power to the relays on or off. 
Table 2 on page 15 shows the uses of the pins of port B, for this purpose. By reading 
a status byte from Port B, we can ascertain the position of each relay. Table 3 on page 
16 shows the uses of the pins of port B 2 for this purpose. 

Let us designate as relay, the relay controlled by pin / of port B,.10 Valid relays 
are relay, through relay s . 

There is no relays since bit 0 of port B[ has a special purpose. If bit 0 of Port 
B, is a 1, then eligible relays will be switched on. If bit 0 of Port B, is a 0, then eligible 
relays will be switched off. Placing a 1 in bit I of Port B, makes relay, eligible for 
switching. Finding a 1 in bit / of port B 2 means relay, is on. 

Once we have issued a command to alter the position of one of the relays, we 
place a 1 in bit 4 of port C, for 20 ms to permit the command to take effect, then put a 
0 in that bit. 



10 Note that pin i of port B, refers to the same relay as does pin i of port B 2 . 
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III. THE MATCHED FILTER 



This chapter describes the design of a filter whose purpose is to detect the presence 
of the 600 Hz tone characteristic of the space shuttle’s Auxiliary Power Unit (APU). 
This circuit has not yet been built and tested, but the most critical sub-circuit, the 
bandpass filter it uses, has been simulated. The results of the simulation match the 
predicted performance very closely and are included in this chapter. 

The existence of the tone and the equation of a fourth-order elliptical (Cauer) 
bandpass filter for detecting its presence are documented in Jordan [Ref. 6]. While the 
thrust of Jordan's work was to develop a digital filter, the implementation described in 
this thesis uses analog electronics. This implementation has the advantage that it can 
be constructed expeditiously with readily available components and requires less elec- 
trical power. The digital implementation described by Jordan requires special hardware 
and components. In particular, the Intel 2920 Digital Signal Processor integrated circuit 
he proposed to use is no longer in production. Jordan does propose an analog imple- 
mentation in addition to the digital one. It requires six operational amplifiers; the design 
proposed here requires only four, and so require less power to operate. This is important 
in this application, since power is limited. 

The term matched filter ordinarily refers to a particular kind of filter based on 
autocorrelation. However, the term has come to be applied incorrectly to the bandpass 
filter used to detect the application of power to the Auxiliary Power Unit. Rather than 
abandon the term matched filter . which has become thoroughly entrenched in the doc- 
umentation of the Vibro-acoustic experiment, this author will continue to use (misuse) 
it to denote a narrowband filter whose purpose is to respond to the characteristic 
600 Hz tone emitted by the space shuttle’s Auxiliary Power Units beginning about five 
minutes before launch. Figure 2 on page 22 is a block diagram of the author’s proposed 
design for the matched filter. 

A. MICROPHONE INPUT STAGE 

The microphone input stage is shown in Figure 3 on page 23. It uses a Panasonic 
WM-063T microphone. A 620 Q resistor limits the current through the microphone to 
8 mA. The output is an AC signal superimposed on a DC bias. 
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MATCHED FILTER 




Figure 2. Block diagram of the Matched Filter. 

B. HIGH-PASS FILTER 

Figure 4 on page 24 shows the high-pass filter which connects the microphone to 
the pre-amplifier. T he purpose of this filter is to eliminate the DC bias from the micro- 
phone signal. While simple AC coupling can in principle be provided by a capacitor 
alone, a resistor to ground must be included to provide a path for DC from the non- 
inverting lead of the pre-amplifier. Even though the input bias current of the OPA1 1 1 
operational amplifier used to implement the pre-amplifier is less than 2 pA, if this were 
neglected, charge would accumulate on the coupling capacitor and the amplifier would 
saturate. 

The cut-off frequency of the high-pass filter was set quite low, at 

^ c ~ 2nRC ~ 2tt( 150 KS2)(150 nF) = 7 Hz ‘ (2) 

Since the signal of interest is well above this, at / = 600 Hz, the filter introduces no sig- 
nificant attenuation or phase shift. 
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C. PREAMPLIFIER 

Figure 5 on page 25 shows the pre-amplifier, which boosts the microphone output 
voltage by a factor of 11 (21 dI3) using a non-inverting configuration of the OPA-111 
operational amplifier. The OPA-111 has a very low noise of less than 40 nV/ v Hz at 
/= 1<>0 I Iz; at higher frequencies it is even lower. Thus the microphone input is boosted 
to reasonable levels without injecting significant noise into the signal and is buffered 
prior to the bandpass filter. 

D. FOURTH-ORDER. ELLIPTICAL (CAUER), BANDPASS FILTER 

Jordan (Ref. 6: p. 45J gives an analog implementation of a fourth-order, elliptical 
(Cauer), band-pass Filter. The design provided below reduces the number of operational 
amplifiers by two, from six to four. 

The coefficients of the necessary transfer function are given in [Ref. 6: p. 36] and are; 

= s 4 + 2.9587 x 10 V + 1.8691 x 10 14 

5 j 4 + 2.4351 x loY + 2.7642 x loY + 3.3558 x I0 9 s + 1.8991 x 10 14 ' 

The author used a computer program to find the roots of this transfer function, which 
can be rewritten as follows: 
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C(5) 



(5 + y'4.49 x 10 , )(5 — y’4,49 ; 

(i + 62 4- / 3 .84 x lO'Hs + 62 - ;3.84 x 



in’)(i + ;3.07 x 10V — >3.07 x m 1 ) 



By multiplying together the terms containing complex conjugates of each other, we ob- 
tain the biquadratic representation of this function. 



G(s) = 



5 J + (3.06S X in 5 ) 2 

(imi) j+c , 586 x -^r 



2 + (4.491 x 10 1 ) 2 






(5) 



Each of the factors in this expression has been w ritten in the form 
s 2 4- col 



F(s) = 



-■*(?) 



S+(O c 



( 6 ) 



This is the equation of a notch filter, given by Ghausi [Ref. 12: p. 16J, If cu,= oj p , then 
the notch filter is symmetric, that is, the attenuation curve to the left and right of the 
notch frequency is symmetric about that frequency when the transfer function is plotted 
on a logarithmic frequency scale. The first factor in equation (5) has a), < w p . Conse- 
quently, this factor represents a high-pass notch filter. The magnitude of (7(5) rises once 
c 0 in 5 =jco exceeds co 2 ; it levels off once c 0 exceeds (o p . By contrast, the second factor in 
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PRE-AMPLIFIER 




Vou t 



Figure 5. Pre-amplifier. 

equation (5) has uo 2 > cu f . Ihercfore, this factor represents a low-pass notch filter. The 
magnitude of G(s) drops once to in 5 = jo) exceeds top. it levels off once to exceeds co 2 . A 
low-pass notch filter and a high-pass notch filter placed in cascade form a bandpass filter 
if suitable choices for to f and io r are made in each case. 

It can be difficult to implement cascaded filters successfully. However, the cascade 
filter is very attractive due to its simplicity, and for this reason we have employed it here. 
The design presented has been simulated and so we believe it would be quite straight- 
forward to implement it in hardware. 

The three forms of notch filter and the bandpass filter formed by cascading a low- 
pass and a high-pass notch filter are shown in Figure 9 on page 29. Three of these 
curves were calculated by computer from the factors in the transfer function given in 
equation (5). The symmetrical notch filter transfer function plotted in the figure is an 
example of what results from equation (6) when cu, = (o 2 . It, too, was calculated by- 
computer from the transfer function. When the high-pass notch filter is multiplied by 
(put in cascade with) the low-pass notch filter, the bandpass filter shown in the figure 
results. By using asymmetrical notch filters, as opposed to symmetrical ones, we can 
obtain high gain in the passband. In this region both notch filters have high gain and 
so reinforce one another. 
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Plot of an Elliptical 4th Order 
Bandpass Filter 




Figure 6. Magnitude of the transfer function of the elliptical bandpass filter. 

The transfer function for equation (5) is plotted separately in Figure 6 on page 26; 
this plot, too, was generated by computer. The advantage to writing the equation for 
the elliptical band-pass filter in the form of equation (5) is that it is a comparatively 
simple matter to implement biquadratic filter sections using operational amplifiers; by 
cascading these sections, the entire transfer function can be implemented. Again, it can 
be difficult to implement this scheme. 

Figure 7 on page 27 shows a schematic for a generalized biquadratic filter using two 
operational amplifiers. The blocks labeled with the letter “Y” represent admittances. 
'I he design equations for these two filter sections are derived in APPENDIX A. Deri- 
vation of Design Equations for the Matched Filter on page 71. For the high-pass notch 
filter, they are 
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Figure 7. A generalized biquadratic filter using tuo operational amplifiers. 



v a 


(7) 




(8) 


jj-Q-z,— J- 

L b 


(9) 


-r, = -L~z a = z,-R 


(10) 


>6 = = 00 


(ID 


K ’ = 5C ‘~ Z ’ = 7q 


(12) 




(13) 
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r 0 U R T H - 0 R D E R ELLIPTIC 
BANDPASS RILTER 

GAIN r 30 dB AT f = 600 Hz 
ATTENUATION = 0 dB AT f < 500 Hz AND f > 700 Hz 
3 dB BANDWIDTH * 50 Hz 



H '"LF444 27 9o 



AC SI GNAL IN 



T>r 




Figure 8. A fourth-order, elliptic bandpass filter with Q = 12: It provides 30 dB 

of attenuation outside the passband. 
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Figure 9. Notch filters: Symmetric, low-pass, and high-pass notch filters: and a 

bandpass filter formed from a low-pass and a high-pass notch filter in 
cascade. 
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(14) 



For the high-pass notch filter, co 2 = 3.068 x 10\ <o p = 3.586 x 10 3 , and Q p = 30.5. Hence 

“■=8.176. (16) 

If we make the arbitrary choice C b = 10^ F, then we get C a = 1.22 ^F , R = 27.9 £2, 
Z 3 = R i = 100 KQ, Z, = R x = 818 KQ , and Q P R = 851 Q. Note that Z x is a resistor 
whose magnitude in ohms is the reciprocal of the magnitude of C a in farads. Similarly, 
Z 3 is a resistor whose magnitude in ohms is the reciprocal of the magnitude of Q in 
farads. The apparently arbitrary choice for Q was actually not random. This circuit 
must be made with components whose stability is high to minimize changes in per- 
formance due to changes in temperature. Capacitors with low temperature coefficients 
are available in polystyrene up to values of 10 ^F. Using this value for Q allows R x not 
to be too big, and R not to be too small. 

For the low-pass notch filter, the design equations are 



lWs = -^~Z, = Z s = R 1 , 


(H) 


>2 = >7 NC— Z l = Jc 


(18) 


Y 3 -Y,--ji-~Z 3 -Z t -R. 


(19) 


Y 6 = 0~Z 6 = oo 


(20) 


Y ‘ = QA = QpRb 


(21) 




(22) 
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(23) 



For the low-pass notch filter, a> 2 = 4.491 x 10 3 rad, s, to p = 3.843 x 10 3 rad s, and 
Q,= 31.0. So 



H.35. (24) 

If we arbitrarily pick R b = 1 KQ, then R„ = 1 1.4 KQ, C= 260 nF, and Q p R b =31 K Q. 
Figure 8 on page 28 shows the complete bandpass filter. We have used the LF444 Quad 
Low Power JFET Input Operational Amplifier. It has an extremely low input bias cur- 
rent of 50 pA at most, and only 35 nV/ % Hz noise voltage. 

We simulated the frequency response of this filter using Micro-Cap III [Ref. 13]. 11 
We found that it performed almost exactly as predicted. Figure 10 on page 32 is a plot 
generated by Micro-Cap III from its simulation. By comparing this plot with that gen- 
erated from the transfer function in Figure 6 on page 26. we see that the only departure 
from the predicted performance is a slight asymmetry 7 in the ripple in the passband. 
Since we are concerned only with detection of the Auxiliary Power Units’ acoustic sig- 
nature, and not with faithful reproduction, this is not a matter for concern. The center 
of the passband and the location of the upper and lower notch frequencies are at the 
predicted frequencies. The gain in the passband also is as predicted. The simulation 
results are strong evidence of the correctness of the analysis and the feasibility of the 
design. 

The operational amplifier in the Pre-amplifier is an OPA1 1 1. Its output impedance 
is 100 Q. The input impedance of the bandpass filter is well above 10 kQ throughout 
the passband. The bandpass filter therefore does not provide a significant load on the 
Pre-amplifier, and so the simulation results can be considered to be quite accurate, even 
though they were produced with an assumption of zero output impedance from the 
Pre-amplifier. 



1 1 In the simulation, we used two LF442 operational amplifier packages instead of a single 
LF444 operational amplifier package. These two packages provide operational amplifiers with 
identical electrical characteristics, which justifies the substitution made. 
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Figure 10. Frequency response of the simulated bandpass filter: This plot was 

obtained using Micro-Cap 111 [Ref. 13). The phase response also is 
shown. It is the curve with the staircase-like appearance. The gain 
response is nearly identical with that generated by computer and shown 
in Figure 6 on page 26 . 

E. ADJUSTABLE GAIN 

Figure 1 1 on page 33 shows how a single LF444 operational amplifier is configured 
as a non-inverting amplifier of variable voltage gain up to 28 (29 dB). The gain is to be 
adjusted so that the strongest output signal has 3 V peak-to-peak. This maximum signal 
is that which exists when the Auxiliary Power Unit outputs its characteristic tone. 

F. FULL- WAVE RECTIFIER 

Figure 12 on page 34 shows the design of a full-wave rectifier. It converts the 600 
IIz tone admitted by the band-pass filter into a fluctuating direct current signal. This 
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circuit is modified from an absolute value circuit provided by Jung [Ref 14: pp. 236-237J. 
It operates as follows: 

The inverting terminal of both operational amplifiers is at \irtual ground. There- 
fore. on the positive cycle of the incoming signal, current passes through resistor to 
the inverting input of the first operational amplifier. This current is unable to enter the 
operational amplifier because of its extremely large input impedance: nor can it pass 
through diode D 2 , since that diode will only pass current in the other direction. Con- 
sequently, it passes through resistor /?,. At point a. the voltage is the negative of the 
input voltage. The same amount of current flows through resistor R 3 . Resistor 7? 4 has 
only half the resistance of R 3 , so it draws twice the current that resistor R 3 can supply. 
The balance comes through resistor R s . This causes the output of the second operational 
amplifier to match that of the input to the circuit. So during the positive cycle of the 
input, the input voltage is duplicated at the output. 

On the negative cycle, the two diodes serve to keep the voltage at point a at ground 
potential. This eliminates all current through resistors R 2 and R 4 . 1 he eflect is the same 
as if the first operational amplifier were removed entirely. The second operational am- 
plifier is then in the usual configuration for inverting. The inverse of the negative input 
signal is, of course, a positive signal. 
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Figure 12. Full-nave rectifier. 

In summary, whether the input is positive or negative, the output is the absolute 
value of the input. 

G. LOW-PASS FILTER 

The signal out of the rectifier has a fundamental frequency of 

2 x 600 Hz = 1200 Hz and this is superimposed on a DC voltage derived as follows: 

v(0 = rsin(2jr//) 

= J'sin(co/) ^ ' 



FULL - WAVE RECTIFIER 
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figure 14. Second-order, lou-pass filter. 
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The signal into the filter has a peak amplitude of 1.5 V. Application of this formula 
gives V AV = 0.955 V. This is the amplitude of the strongest signal we expect to receive 
from the Auxiliary Power Unit. 

The low-pass filter which follows the rectifier is designed to have a cut-off frequency 
of/ = 5 Hz. This frequency is well below the fundamental frequency of 1200 Hz passed 
by the rectifier. As a consequence, only the average signal V AV we have just derived will 
be present at the output. 

The circuit is based on the general circuit shown in Figure 13 on page 35. The de- 
sign equations for this circuit are derived in APPENDIX A. Derivation of Design 
Equations for the Matched Filter on page 72 and are reproduced here. 

C,=4C,e, 2 (27) 



r i = r 2 = r = 



1 

<V'C,C 2 



(28) 



In this application, we are not concerned with the phase of the signal. Therefore it is 
reasonable to seek a maximally flat transfer function. To do this, we implement a 
second-order Butterworth filter, for which 



Q P = -U- 0.707. 

Given our nominal cut-off frequency / = 5 Hz, we arbitrarily choose C 2 = 220 nF. We 
get C, = 440 nF, and R = 102.3 k£l Since the cut-off frequency is not critical, w r e can 
pick the more convenient component values C, = 470 nF and R = 100 k£l The resultant 
cut-off frequency is / = 4.9 Hz and Q b = 0.731. Since the purpose of this low-pass filter 
is to find the average of the rectified 600 Hz tone, this deviation from the design pa- 
rameters is quite acceptable as the cut-off frequency still is well below the fundamental 
frequency of 1200 Hz created by full-wave rectification of the 600 Hz tone. 

The chief benefit provided by this filter is a roll-off of 40 dB, decade when 
/>/ = 4.9 Hz. This amounts to 96 dB attenuation when / = 1200 Hz, which is ample 
to suppress the AC component in the signal out of the full-wave rectifier. Figure 14 on 
page 36 shows the component choices and circuit for the second-order low-pass filter. 
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Figure 15. Threshold detector. 

H. THRESHOLD DETECTOR 

Figure 15 on page 38 shows the design of a threshold detector. There is some evi- 
dence that other sources of 600 Hz signals that might be present simultaneously will be 
15 dB below this. The voltage which is 15 dB below 0.955 V is 0.170 V. Any signal 
which exceeds the 0.170 V threshold just derived should cause the threshold detector to 
signal that a sufficiently strong 600 Hz signal is present. Presumably this signal is from 
the Auxiliary Power Unit. The threshold detector uses an LM358 operational amplifier. 
This device requires only a single power supply and it tends not to “latch up” when 
configured as a comparator. Its output goes high (to 5 V) whenever the threshold is 
exceeded. Otherwise, its output is held low (at ground). 

I. RESETTABLE PULSE COUNTER 

Figure 16 on page 39 shows the Resettable Pulse Counter. Its purpose is to signal 
the presence of a 600 llz signal from the Auxiliary Power Unit if it has been contin- 
uously present for 73.1s. Spurious signals with a component at f = 600 Hz may be 
present intermittently. We do not expect them to be continuously present at levels more 
than 15 dB below that of the strongest signal expected from the Auxiliary Power Unit. 
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RESETTABLE PULSE COUNTER 




Figure 16. Resettable Pulse Counter: 1 his circuit decides that the APUs are on 

il it gets a signal from the threshold detector lor 73.1 s. 



Consequently, the Resettable Pulse Counter has the effect of eliminating false triggering 
due to these spurious signals. 

Whenever the threshold detector indicates the presence of the 600 IIz tone charac- 
teristic of the Auxiliary Power Unit, it produces a high output. This signal is applied to 
the LOAD(L) input of the Resettable Pulse Counter. This permits the counter to begin 
marking oir the pulses which arrive from the Pulse Generator, described below. Because 
the pre-load inputs A through D all are connected to ground, the counter will count from 
zero to 15, at which point its CO output will go high. Thus, the counter will permit 
sixteen pulses to arrive from the Pulse Generator before it goes high. Since the pciiod 
of these pulses is T = 4.57 s, the output will go high if 14 x 4.57 s = 73.1 s elapses. 
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Configuration of an LM555 Timer 
for Astable Operation 




Figure 17. Astable operation of the LM555 Tinier to generate a pulse train. 

J. PULSE GENERATOR 

This module is based on the LM555 Timer integrated circuit. The data sheet for this 
circuit provides equations to permit choosing component values to provide the desired 
period and duty cycle. The duty cycle is not critical to this application. Figure 17 on 
page 40 shows the general configuration for astable operation, which is the mode of 
operation which produces a periodic signal. The design equations arc: 



i charge = 0.693(R A + R B )C 


(30) 


1 discharge = 0.6937? B C. 


(31) 



Thus the total period 

= * charge T * discharge = 0.693 (R a + 2 R b )C. (32) 
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Sohing for C we get 



C = 



T 

0.69 }[R a + 2 R e )C 



11 mF 



(33) 



and the duty cycle 



D = 



R a + 2^ 



(34) 



Picking R 4 = Rg = 200 K£2 provides a duty cycle D = 0.333 , which is perfectly accepta- 
ble for this non-critical parameter. 

Figure 18 shows a Pulse Generator based on this configuration. This circuit 
produces a regular stream of square pulses of period 7 = 4.57 s. These are used by the 
Resettable Pulse Counter to measure the amount of time when a reasonably strong 600 
Hz signal is present. 
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K. SUMMARY 

This completes the description of the somewhat inappropriately named matched fil- 
ter. Simulation of the bandpass filter used in the matched filter has shown that that part 
of the design is correct and feasible. The implementation and testing of the bandpass 
filter and the other components of the entire circuit remain to be done in the future. 
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IV. DESIGN OF THE CONTROL SOFTWARE 



In describing the software which operates the controller hardware, we shall adopt 
the following conventions. 

We will show variable names in bold, e.g., variable; function names in bold with 
(possibly empty) parentheses at the end, 12 e.g., function(), and constants in uppercase, 
e.g., CONSTANT. 13 We shall also use bold for the names of regions, described below in 
Section A. Memory Map. Development of the software for the Vibro-acoustic Exper- 
iment was done under the Microsoft Disk Operating System (MS DOS). Figure 35 on 
page S9 shows how we arranged the hierarchy of files containing the source code, object 
code, header files, ere. See APPENDIX D. HIERARCHICAL ORGANIZATION 
OF SOFTWARE FILES on page 8S for a more complete discussion of this organiza- 
tion. 

A. MEMORY MAP 

Figure 19 on page 44 shows the addresses of the ROM and RAM in the computer. 
Our NSCSOO-based controller provides for up to eight EPROMs and RAMs in any 
combination, each holding 8 KBytes. The wiring of the printed circuit board permits 
placing a RAM chip in any of the addresses evenly divisible by 0x2000 {e.g., 0x0000, 
0x2000, 0x4000. etc.) The addition of a jumper wire permits the RAM chip to be re- 
placed by an EPROM. 

The NSCS00 uses the same architecture as the Z-80 [Ref. 10]. Because the Z-80 
architecture causes execution to begin at address 0x0000 whenever power is applied, it 
is necessary to install an EPROM at location 0x0000. It was therefore convenient for 
us to put all EPROMs at the low end of memory, and all RAMs at the high end. AP- 
PENDIX C. HOW THE UNIWARE SOFTWARE USES THE COMPUTER 
MEMORY on page 86 explains the way in which the Uniware C Compiler employs the 
memory. 



12 According to custom in the C programming language. 

13 In C. constants are declared using the #defme directive. These are stored in various header 
files such as >ibro.h. 
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Figure 19. Memory map of the computer: This figure shows the locations of 

ROM, RAM, and the eight software regions. The ROM and RAM 
addresses are specified by the hardware design. The addresses of the 
regions are specified by the linker. 
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B. OPERATION OF THE VIBRO-ACOUSTIC EXPERIMENT 
1. Menu-driven Diagnostic Program 

Some years ago the film Alien was produced. Asa part of the publicity cam- 
paign attending its release was the slogan, “In space, no one can hear you scream.’’ 
Similarly, when the Vibro-acoustic Experiment is performed in the Space Shuttle, there 
will be no one to hear it scream, that is, to monitor the progress of the experiment. 

This is quite different from the situation on the ground, where generally there 
is a monitor attached, and there is someone monitoring execution of the program. 
Furthermore, there is a need on the ground to test components of the experimental 
package without running the experiment from start to finish. For example, we have 
found it helpful to be able to operate the bubble memory module attached to the con- 
troller hardware in a manual mode. By this means, we have debugged the software and 
ensured that it can operate the bubble memory successfully before attempting to use it 
in our application. 

An obvious way to allow software to be tested on the ground but used to run 
the experiment in space would be to compile a different program for each purpose. This 
is. to put it mildly, a very inconvenient approach. Not only must two distinct programs 
be managed, but assurance that the diagnostic version works gives little assurance that 
the operational one will work. We have elected to have a single program, usable under 
all circumstances. This requires that the program be able to recognize that someone is 
monitoring it. To do this, it simply checks bit 3 of port C, to see if a terminal is con- 
nected to the R.S-232C serial interface. (See Table 6 on page 18.) If there is no terminal 
attached, the program assumes that there is no one n nitoring execution, /.<?., the ex- 
perimental package might very well be in space, and so the experiment should be oper- 
ated. If there is a terminal attached, then the package cannot possibly be in space, since 
we don't intend to include a monitor in the Space Shuttle. In this case, the control 
program does not operate the experiment. Instead, it presents to the operator a series 
of menus of choices from which the operator can choose which part of the system to 
exercise. 

The menu subsystem provides the following capabilities: 

1. Software reset. This has an effect similar to that caused by removing power and 
then applying it again. 

2. Real-time clock control. The user can set the date and time, read them, or test a 
time-out feature used to synchronize events during the experiment. 
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3. Power subsystem control. Individual subsystems can be powered up or down under 
the user’s control. 

4. Bubble memory control. The bubble memory used for storing a log of events per- 
formed during the experiment can be powered up or down, initialized, or tested 
under the user’s control. These tests are at a very low level. Data stored in the 
bubble memory' consists of character strings, and these are unformatted. The data 
are not treated as formatted log entries.14 

5. Analog-to-Digital (A/D) converter control. Any of the temperatures and voltages 
accessible through a channel of the on-board A/D converter can be read under the 
user’s control. 

6. Running the experiment. This causes the Vibro-acoustic experiment to be per- 
formed. The only difference between operating the experiment under menu control 
and operating it with no terminal attached is that with a terminal, a large amount 
of diagnostic information is displayed during execution. Without a terminal at- 
tached. this information is lost. The advantage to this approach is that if the ex- 
periment works on the ground, we are assured it will work in space, since essentially 
the same code is executed in both cases. 

7. Perform port input and output. This is a very low-level test. Characters of data can 
be written to or read from a port at any address, one at a time. This is helpful in 
debugging the software. 

8. Display contents of the controller’s memory. This, too, is a very low-level routine 
useful only for debugging. 

9. Examine or change bubble memory. These routines permit the formatted contents 
of the bubble memory log to be displayed in a readable manner on the terminal. 
In addition to allowing debugging to be done, this operation permits the 
experiment’s operation to be tailored in advance. 

Each of these menu items leads to a further menu of functions to permit the 
operator to test all subsystems of the experiment. These routines are discussed in detail 
in the software description contained in Section A. Major Subroutines and Functions 
on page 108. 

2. Performing the Experiment 

This section describes in detail the steps of the experiment. These steps are il- 
lustrated in the flowcharts contained in the following pages. 
a. Microprocessor Control Program 

Flowchart 0 in Figure 20 on page 48 shows the overall structure of the 
control program. The program begins executing when power is first applied to the sys- 
tem. After initializing the hardware for proper operation, it checks to see whether or 
not there is a terminal attached. If not, it proceeds on the footing that it should run the 



14 There are additional bubble memories within the Solid State Data Recorder (SSDR) which 
are not tested by these routines. 
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experiment, bypassing all the menu routines. If, on the other hand, a terminal is con- 
nected. then the program deduces that the experiment is not being run in space, where 
no terminal will be available, and so it enters the menu subsystem. The experiment is 
not performed unless the user specifically requests this later. 

b. Initialize Hardware 

Flowchart 1 in Figure 21 on page 49 is a more detailed look at block 1 of 
Flowchart 0 in Figure 20 on page 48. The first initialization task to be performed is to 
let the programmable input output devices know which data lines are for input and 
which are for output. There are two clocks which also must be initialized. One of these 
provides a clock signal for serial communications at 9600 baud. The other provides a 
clock for conversion of data from analog to digital form. 

c. Run the l ibro-acoustic Experiment 

Flowchart 2 is shown in Figure 22 on page 50. It is a more detailed look 
at block 2 of Flowchart 0 in Figure 20 on page 4S. 

One of its first tasks is to initialize certain variables in the software. It then 
ascertains (by consulting a record in the bubble memory) whether the full experiment 
or the abridged version is to be performed. The full experiment consists of the sweep, 
scroll, launch, and post-launch phases already described in Chapter 1. INTRODUC- 
TION on page 1. The scroll phase is omitted if the Auxiliary Power Units (APUs) are 
not detected before the launch was detected. 

In the abridged experiment, the program initially checks to see if the 
barometric switches have been triggered, which they would have been were the Space 
Shuttle already in space. This check is done to avoid entering record phase a second 
time when the space shuttle is already aloft. Such a situation might arise after a power 
fault during lift-off; to recommence record mode would erase the acoustic data recorded 
during the launch. 

The next decision to be made is whether or not to enter record mode. 
Conceivably, the Auxiliary Power Units could be detected and the record phase entered 
at some point, but the launch might then be scrubbed. If power were not removed from 
the experiment, then the control flow’ would permit record mode to be commenced anew. 
Why not just start record mode again? Operating the Solid State Data Recorder with 
its bubble memories consumes considerable power. We cannot afford to waste that 
power by, in effect, continuously operating the recorder unnecessarily. The decision not 
to let this mode be begun again until at least 12 hours after the last time will prevent this 
from happening. Also, if a power fault occurred after the record phase began, we would 
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Figure 20. Flowchart 0: '1 his is the highest level of flowchart in the hierarchy. 

Processing begins here when the controller first receives power. 



prefer to avoid interfering with the Solid State Data Recorder (SSDR). which might still 
be operating successfully in record mode. This safeguard will ensure that such interfer- 
ence does not occur. If a mission is sciubbed, it would not be rescheduled for at least 
24 hours. The 12 hour wait is long enough to avoid interfering unduly with the SSDR 
and to preclude wasting power and is short enough to permit correct operation when the 
launch is rescheduled. 

Once either the Auxiliary Power Units or any launch indication are de- 
tected, record mode can be entered. Normally, upon completion, we expect to be in 
space. In this case, control will be passed to the post-launch phase of the mission. 
Otherwise, the mission must have been aborted and the 12 hour wait begins. 
d. Initialize Software 

Flowchart 2.1 in Figure 23 on page 51 is a more detailed look at block 2.1 
of Flowchart 2 in Figure 22 on page 50. Initializing the software entails discovering 
what the current status of the experiment is. For example, this might be the first time 
power has been applied, in which case the sweep phase has not been performed yet, and 



48 




Figure 21. Flowchart I: The flowchart shows the initialization of hardware and 

software at the very beginning of program execution. 



the launch has not taken place. Or perhaps the sweep was performed previously, but the 
Space Shuttle still is on the ground. This information was stored previously in the 
bubble memory log, and it must be retrieved before the controller can know what it 
should do. 

The controller also turns off the Voltage Controlled Oscillator for safety 
reasons. Because the speaker connected to it emits such a loud tone, it would be dan- 
gerous to allow it to operate until the controller can first see whether it has been begun 
once before. If NASA eventually agrees to permit the sweep phase to be performed, they 
will almost certainly afford us only one opportunity to perform it. If it does not com- 
plete successfully, there is no second chance. The heater subsystem also is deactivated 
as a power-saving measure until the controller can find out exactly what to do. 
e. Do Sweep 

Flowchart 2.2 in Figure 24 on page 52 is a more detailed look at block 2.2 
of Flowchart 2 in Figure 22 on page 50. If the sweep phase ever was started before, or 
if the launch was performed previously, the sweep phase is skipped. Otherwise the con- 
troller notes in the bubble memory log that it has now started the sweep phase, which 
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Figure 1 . 




CD 



Flowchart 2: This flowchart shows the steps entailed in both the full 
and the abridged versions of the Vibro-acoustic Experiment. 
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will ensure that it never tries to restart it. The controller now causes echoes of known 
frequencies to be recorded. 

I hc controller expects to be infomicd of the completion of the sweep phase. 
However, a 13 minute timeout is initiated to make sure that the controller does not wait 
forever for this information. 

J. Start Recording Response at Known Frequencies 

Flowchart 2.2.2 in Figure 25 on page 53 is a more detailed look at block 
2.2.2 of Flowchart 2.2 in Figuie 24 on page 52. It shows the steps entailed in initiating 
the sweep phase. The Analog to Digital Converter Subsystem must be turned on first, 
since the converters power the microphones which receive the acoustic signal. The 
Voltage Controlled Oscillator (VCO) can then be started, followed by the Solid State 
Data Recorder (SSDR). Starting the SSDR requires first applying power to it and then 
commanding it to enter sweep mode. 

g. Stop Recording Response at Known Frequencies 

Flowchart 2.2.4 in Figure 26 on page 54 is a more detailed look at block 
2.2.4 of Flowchart 2.2 in Figure 24 on page 52. It shows the steps entailed in termi- 
nating the sweep phase. These steps are to remove power from three subsystems: the 
Voltage Controlled Oscillator (VCO), the Solid State Data Recorder (SSDR) and the 
Analog to Digital (A D) Converter. 
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Figure 24. Flowchart 2.2: This flowchart shows the steps entailed in performing 

the sweep phase of the experiment. 
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periment. 

/«. Wait for APUs to Start or for Launch Indications 

Flowchart 2.3 in Figure 27 on page 55 is a more detailed look at block 2.3 
of Flowchart 2 in Figure 22 on page 50. There are two possible indications of a launch. 
One is a signal from the Vibration-activated Launch Detector circuit. The other is a 
signal from the barometric switches. If either of these is present, the flag LAUNCHED 
is asserted. Otherwise, the controller will check to see if the Auxiliary Power Units 
(APUs) have been detected. If so, the flag APUs ON is asserted. If no indications are 
present, the controller will continue looking for them indefinitely, 
i. Do Scroll 

Flowchart 2.4 in Figure 28 on page 56 is a more detailed look at block 2.4 
of Flowchart 2 in Figure 22 on page 50. It shows the steps entailed in performing the 
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Figure 26. Flowchart 2.2.4: This flowchart shows the steps entailed in stopping 

the recording of known frequencies during the sweep phase of the ex- 
periment. 



scroll phase. Power is applied to the Solid State Data Recorder (SSDR), and it is then 
commanded to enter scroll mode. 

The mission will be scrubbed if no launch occurs within seven minutes after 
the Auxiliary Power Units are started. We initiate a ten minute timeout, which is con- 
servative. If at the end of ten minutes no launch indications have been detected, the 
program aborts; otherwise, it asserts the LAUNCHED flag. 

j. Abort 

Flowchart 2.4.4 in Figure 29 on page 57 is a more detailed look at block 
2.4.4 of Flowchart 2.4 in Figure 28 on page 56. It shows that when the mission is 
deemed to have been aborted, power is removed from all subsystems. 

k. Do Launch 

Flowchart 2.5 in Figure 30 on page 58 is a more detailed look at block 2.5 
of Flowchart 2 in Figure 22 on page 50. The flowchart shows the steps entailed in 
performing the launch phase of the experiment. The first step is to determine whether 
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Figure 27. Flowchart 2.3: This flowchart shows the steps entailed in listening for 

the Auxiliary Power Units (APL's) while simultaneously waiting for in- 
dications of a launch. 



this is necessary or not. If the launch was ever determined to have been completed in 
the past, the LAU NCH DONE will have been asserted then. In this case, it is not ap- 
propriate to perform this phase a second time and so all the blocks in this flowchart will 
be skipped. Otherwise, the Solid State Data Recorder (SSDR) is conunanded to leave 
scroll mode and enter launch mode. Within two minutes of the time of launch, there will 
no longer be any air in the Space Shuttle's cargo bay. We initiate a three minute timeout 
so that, in the event that the SSDR fails to signal completion of the launch phase, the 
controller will not be stuck permanently in launch mode. The controller repeatedly 
checks either for a completion signal from the SSDR or for a timeout. 

/. Check for a Completed Launch 

Flowchart 2.5.3 in Figure 31 on page 59 is a more detailed look at block 
2.5.3 of flowchart 2.5 in Figure 30 on page 58. If the LAUNCH DONE flag ever was 
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DO SCROU 



Figure 28. Flowchart 2.4: 1 his flowchart shows the steps entailed in performing 

the scroll phase between the time the Auxiliary Power Units (APUs) 
start operating and the time that the launch is detected. 

asserted, this block does nothing. However, if this flag was not previously asserted, the 
state of the barometric pressure switches is checked. If either of them has tripped, we 
have a positive indication of launch. It is then appropriate to set the LAUNCH DONE 
flag. 
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Figure 29. Flowchart 2.4.4: This flowchart shows what happens when an abort 

condition is detected. 



m. Do Post-launch 

Flowchart 2.6 in Figure 32 on page 60 is a more detailed look at block 2.6 
of Flowchart 2 in Figure 22 on page 50, It shows the steps entailed in pei fanning 
post-launch functions. These are the monitoring Functions required after the Space 
Shuttle has left the earth's atmosphere. 1 he first step is to rcmo\e power from all sub- 
systems. A five minute timeout is then initiated. The effect of this is to permit system 
status to be recorded every five minutes. I he heater subsystem is one of the subsystems 
which needs monitoring. A check is done to ensure that the launch has been recorded 
as complete. These two steps are repeated continually throughout each five minute pe- 
liod. At the -completion of that period, current values of the temperature and voltage 
at various points are read and stored in the bubble memory log. A check also is made 
to see if the voltages on the buses arc too low. If so, the post-launch processing ceases. 

n. Monitor Heater Subsystem Operation 

Flowchart 2.6.3 in Figure 33 on page 61 is a more detailed look at block 
2.6.3 of Flowchart 2.6 in Figure 32 on page 60. It has two branches. In one, the tem- 
perature of the experimental apparatus is suflieiently high, in which case the heater 
subsy stem is deactivated. In the other branch, the temperature is too low and the heater 
subsystem is activated. 

o. Do Record 

Flowchart 2.7 in Figure 34 on page 62 is a more detailed look at block 2.7 
of Flowchart 2 in Figure 22 on page 50. It shows the steps entailed in putting the ex- 
periment into the record phase. Ihcse steps are, first, to put the Solid State Data Re- 
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Figure 30. Flowchart 2.5: This flowchart shows the steps entailed in performing 

the launch phase of the experiment. 



corder (SSDR) into the launch mode, and then to begin a 20 minute timeout, after which 
time the SSDR would have run out of memory in which to store recorded sound. The 
SSDR normally would inform the controller that it has completed operation before the 
timeout occurs. The timeout is meant to permit the controller to leave the record phase 
even if the SSDR fails to signal completion. 
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Figure 31. Flowchart 2.5.3: This flowchart shows the steps entailed in deciding 

whether or not a launch has occurred. The barometric switch is 



deemed to be the most reliable (and only convincing) indication of a 
launch. 



59 




Figure 32. Flowchart 2.6: This flowchart shows the steps entailed in performing 

measurements and monitoring temperatures and voltages after the ex- 
periment is complete. 
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Figure 33. Flowchart 2.6.3: 1 his flowchart shows the steps entailed in monitor- 

ing the temperatures of the bubble memory unit and maintaining that 
temperature abo\e 10"C. 
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Figure 34. Flowchart 2.7: This flowchart shows the steps entailed in performing 

the record phase of the abridged experiment. 
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V. HOW TO GET THE EXPERIMENT READY FOR A LAUNCH 



This chapter explains what must be done prior to the launch of the Space Shuttle 
to ensure that the experiment is performed correctly. The current status of the exper- 
iment is stored in page 0 of the bubble memory log. By setting appropriate information 
there, we can ensure that when power next is applied to the experimental apparatus, the 
correct sequence of steps is performed. 

There are really two possible experiments to be performed: the unabridged exper- 
iment and the abridged one. The abridged experiment dispenses with the sweep, scroll, 
and launch phases of the experiment, replacing them with a single record phase. Which 
of these is to be run must be stored in page 0 before launch. 

A. UNABRIDGED EXPERIMENT 

Attach a terminal to the RS-232C interface and apply power to the experiment. The 
controller will present the following menu on the terminal. 

A Software reset. 

B Realtime clock functions. 

C Power relay switching functions. 

D Bubble memory test functions. 

E A/D converter functions. 

F Run experiment. 

G Perform port I/O. 

H Display contents of controller memory. 

I Examine or change the data logged in the bubble memory. 

Z Exit this menu. 

Choose option (I). The following menu will be presented next. 

A Display page 0. 

B Display a page of the log. 

C Alter the contents of page 0. 

Z Exit this menu. 

Choose option (C). The following menu will next be displayed. 
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A Toggle ' sweepstarted' flag from TRUE to FALSE. 

B Toggle 'launchdone' flag from TRUE to FALSE. 

C Alter value of next available page from 0x12 = 18. 

D Alter value of next available half page from 1 to 0. 

E Toggle ' full_experiment ' flag from TRUE to FALSE. 

F Specify the 'RECORD_start_time’ (make this at least 12 hours before the 
present to permit RECORD mode to be initiated. ) 

Z Exit this menu. 

The menu may not look exactly like this, inasmuch as the flags and page numbers may 
vary. The objective, however, is to set the sweepstarted flag to FALSE; the launchdone 
flag to FALSE; the value of the next available page to 1; the value of the next available 
half-page to 0; the value of the full_experiment flag to TRUE. The value of the 
RECORD_start_time does not matter since the record phase is not performed in the 
unabridged experiment. If a value is already correct, it may be left alone. Only if it 
needs to be changed must the corresponding menu choice be made. 

B. ABRIDGED EXPERIMENT 

For the abridged experiment, follow the same steps as with the full experiment with 
the following differences. The full_experiment flag should be set to FALSE, and the 
RECORD_start_time should be set to some value at least 12 hours before launch. The 
value of the sweepstarted flag does not matter because the sweep phase is omitted in the 
abridged experiment. 

C. BOTH VERSIONS OF THE EXPERIMENT 

Once all the required choices have been made, the controller may be shut off and the 
terminal should be removed. The next time power is applied, the controller will discover 
that no terminal is attached, it will consult the values last stored in page 0 to see what 
it should do, and it will perform the experiment according to those values. 
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VI. TESTING OF THE SOFTWARE 



Every module of the software has been tested individually for correctness. The in- 
tegrated control program also has been tested exhaustively, but because the hardware 
has not yet been completely integrated, there is a limit to what could be accomplished. 
This chapter discusses how the testing has been performed and suggests further tests to 
be done once hardware integration is complete. 

The following hardware components have been completed and have been success- 
fully operated by the integrated software: 

1. Bubble memory for the experiment's log. 

2 . Terminal. 

3. Real Time Clock. 

4. On-board Analog-to-digital (A D) converter. 

5. Voltage Controlled Oscillator. 

6. Power Control Subsystem. 

In addition, a preliminary design of the Solid State Data Recorder (SSDR) was tested 
by Kuebler [Ref. 9]. His tests included a demonstration that the olT-board analog-to- 
digital converters associated with the SSDR functioned correctly, that the SSDR prop- 
erly stored the acoustical data provided to it by the otf-board analog-to-digital 
converters, that this data could be retrived from the SSDR. and that an analysis could 
then be performed on the data. The final version of the SSDR has not yet been com- 
pleted. and in the testing of the software described in this thesis, no attempt has been 
made to emulate its performance. However, the controller dutifully sends commands to 
it and makes repeated (unsuccessful) attempts to read its status information. It also 
notes its inability to get correct responses in the log. 

The software has been tested many times under various conditions, both with and 
without a terminal attached. A test requires the initialization of flags in page 0 of the 
bubble memory log in advance. How to do this is explained in Chapter V. HOW TO 
GET THE EXPERIMENT READY FOR A LAUNCH on page 63. There are two 
ways to end a test, depending on whether or not a terminal is attached. 

1. If there is a terminal attached, pressing CTRL Y will interrupt the experiment and 
present the highest level menu in the diagnostic subsystem. The experiment can 
be resumed by making choice 
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Z. Exit this menu. 



To terminate the experiment completely, make choice 
A. Software Reset. 

2. If there is no terminal attached, simply remove power from the system. This is, in 
fact, how the experiment will be terminated at the end of a space flight (if the bat- 
teries last long enough.) Attaching a terminal and applying power will put the 
control program into the diagnostic subsystem. 

The results of the experiment can be evaluated by making menu choice 

I Examine or change the data logged in the bubble memory. 

The following is a list of the various conditions under which the experiment has been 
tested. The conditions are listed as applying and not applying, where this is meaningful. 
All these conditions resulted in satisfactory performance by the controller. 

1. Terminal present; terminal absent. 

2. Unabridged experiment to be performed; abridged experiment to be performed. 

3. Sweep phase previously performed; sweep phase not previously performed. 

4. Launch had occurred previously; launch had not occurred previously. 

5. Bubble memory space exhausted during test. The controller correctly ceased trying 
to store more data and continued to operate normally without logging its actions. 
This could not be verified without the terminal attached, for with neither a terminal 
nor a bubble memory log. the controller does not generate enough outputs for 
proper verification of its performance. There is no reason to suppose that the re- 
sults would be different with the terminal removed, however. 

6. Temperature out of limits. Operation of the bubble memory ceased. Power was 
applied to and removed from the heater subsystem by commands to the power 
control subsystem. These commands were issued by the subprogram responsible 
for monitoring the heater's operation, namely monitor_heaters(). Although the 
heater subsystem itself has not yet been completed, the associated power relays 
switched correctly. 

7. Detection of the Auxiliary’ Power Units (APUs) by the Matched Filter was and was 
not emulated by toggle switch. The controller responded correctly in both cases. 

8. Detection of launch by the Vibration-activated Launch Detector w r as and was not 
emulated by toggle switch. The controller responded correctly in both cases. 

9. Activation of the Barometric Pressure Switches was and was not emulated by tog- 
gle switch. In the absence of activation of the barometric pressure switches, the 
presumption is that launch did not occur. The controller responded correctly in 
both cases. 

10. Power was removed abruptly at various points in the procedure and then was re- 
stored. The controller recovered in the desired manner. 
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After each test, the contents of the bubble memory log were examined to see what steps 
in the experiment had been performed. Two obvious differences were found between the 
system's behavior with and without a terminal attached. One of these was that with a 
terminal attached, the diagnostic messages issued during the performance of the exper- 
iment were visible. The other was that with a terminal attached, the diagnostic subsys- 
tem did not get control. No other difference could be found between system behavior 
with and without a terminal attached. 

There is even’ reason to believe that the control program will work as well in the 
Space Shuttle as it has in the lab. The same tests should be performed again once the 
hardware is completely integrated. The only tests which have not already been done are 
those associated with the operation of the Solid State Data Recorder (SSDR). The 
interface with this device is very simple. The controller sends commands and reads sta- 
tus information. The SSDR is otherwise completely independent of the controller. We 
have already ascertained that the application of power to the SSDR through the power 
control subsystem is done correctly. We have also verified correct response to a failure 
of the SSDR to perform as expected. The only thing we have not tested is the response 
of the control program to correct responses from the SSDR. Since the response amounts 
to making a note of the correct response in the bubble memory log, we do not anticipate 
any difficulty in this area. The ability of the controller to send commands to the SSDR 
has been tested, although the response of the SSDR to these commands cannot be 
evaluated until the final version of the SSDR is complete. 

The means of extraction of data from the bubble memory log are not very elaborate 
at this point. Data can be extracted for two experiment steps at one time by providing 
the number of the page in the bubble memory log whose contents are required. No ca- 
pability has been provided for rapid extraction of all data to. say, a microcomputer. This 
does not pose a serious problem, but data extraction would be facilitated by providing 
subroutines to do it quickly. 
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VII. CONCLUSIONS 



The Vibro-acoustic Experiment was the first experiment produced at the Naval 
Postgraduate School for inclusion in a Space Shuttle mission. In view of the consider- 
able technical hurdles it presented, it is fair to say it has been a very ambitious project. 
It has included many disciplines, such as mechanical engineering, thermal engineering, 
digital electronics, analog electronics, acoustics, bubble memory technology, auton- 
omous computer control, software development, a matched filter for detecting an im- 
pending space shuttle launch, power control, and computer-aided design and 
manufacturing (CAD CAM). 

This thesis has concerned itself with overall control of the experiment and with a 
description of one subsystem, the matched filter. It was not possible to do this without 
considering the experiment as a whole. From the author's personal standpoint, this has 
been very' gratifying. We have used a high-level programming language to do the bulk 
of the programming of a microprocessor-based controller, thus avoiding the labor- 
intensive burden of assembly language coding in most areas of the program. We have 
effectively integrated this code with the little assembly code required. We have written 
drivers for assorted hardware devices, such as a terminal, a bubble memory module and 
a real-time clock, thus demonstrating the close association between hardware and the 
software which makes that hardware more than a glorified paper-weight. We have used 
structured programming techniques throughout, thus aiding the design process, as well 
as the understanding of the documentation represented in part by this thesis. We have 
created a conveniently-used software development system, making it straightforward to 
edit the source files, compile or assemble them, link the object modules, list source files 
on a printer, and place the executable file in EPROM. 

This work may benefit others who would like to implement other applications. We 
have made it possible for them quickly to get a device controller programmed and op- 
erating, since so many standard controller functions already exist. The C programming 
language is highly portable, so much of this work would apply even with a new hardware 
design, using, say, a faster microprocessor with more memory. 

Two other projects have already benefitted from the work done here. In one, the 
experimenters plan to obtain voltage versus current for solar cells in space. In less than 
two months, the complete control program for that new application was designed and 
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tested using the same controller and much of the software we have described in this 
thesis. 

In another project now underway, the author is involved in the experimental evalu- 
ation of a thermo-acoustic refrigerator in space. The details of the experimental proce- 
dure in both these cases differ, but the overall fundamentals of control of an experiment 
are the same. Consequently, much of the software described in this thesis can be used 
without any modification. 

For anyone who wants to build a controller with modest requirements for speed and 
RAM, the controller we have used in the Vibro-acoustic Experiment would be suitable. 
By using the work described in this thesis, one can avoid the unpleasant burden of 
starting from scratch. The bubble memory module provides a further 500K bytes of 
random access, non-volatile memory for whatever purpose might be required. 

Work remaining to be done is: 

1. Design, build and test an improved controller which would operate with more 
memory and greater speed. 

2. Convert the existing software to run on the new controller. This would entail re- 
placing the start-up code and other machine-dependent assembly code, and re- 
compiling the C language source code using a compiler which would generate 
machine-language code for the new target machine. Software Development Sys- 
tems. Inc., makes C language cross-compilers which would allow most of the ex- 
isting set-up to be preserved intact. 

3. Modify the existing bubble memory drivers to permit storage of files. At the mo- 
ment. the bubble memory is regarded as a linear list of 64-byte chunks of memory. 
Greater usefulness would result from the provision of a file subsystem. 

4. Produce a manual for other potential users of the software and hardware that 
would make it easy to get new applications up and running quickly. This could be 
supplemented by improved routines to facilitate the generation of executable code. 
At the moment, these routines are specific to the Vibro-acoustic Experiment in that 
they always look in the subdirectory \vibro\contrlr for the files they need. In gen- 
eral, they should permit any subdirectory to be used to hold the files. The exper- 
iment to evaluate solar cell performance used a series of files and subdirectories 
whose structure exactly mimicked the set-up described in this thesis, but no rou- 
tines have been written to set these files up automatically. 

5. Develop or acquire a software maintenance system. Such a system would provide 
better management of successive versions of the control program. It would also 
include a data dictionary to provide a definition of all variables and functions, 
along with a complete cross-reference showing every place these objects were used. 
What would the data dictionary gain us? It often happens that in the course of 
making changes, we inadvertently affect other parts of a system. The data dic- 
tionary would make it possible to find all those places and take appropriate action. 
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Microprocessors have now been in use for just a little over 15 years. The use of 
compiled programs to operate them is an even more recent development, since compiled 
programs generally take up more memory space than assembled programs, and abun- 
dant memory at low prices is available. There are two distinct advantages to using a 
compiler: 

1. The code is easier both to write and to understand. This makes it easier to get 
applications running, and to modify them later, even if team members change over 
a period of time. 

2. The code is much faster to create. This often makes the difference between success 
and failure, since time can be critical, particularly in an educational environment. 

Often these advantages outweigh the disadvantages: 

1, The code tends to take more memory. 

2. The code tends to execute more slowly. 

In the case of the Vibro-acoustic Experiment, these factors were of no great conse- 
quence, except as already noted in conjunction with the bubble memory module. We 
were forced to use assembly code to operate the bubble memory in order to keep up with 
the data transfer rate demanded by it. Had there been an adequate buffer in that hard- 
ware, this extra effort could have been avoided. 

In fact, this last point makes it clear that good hardware design can greatly reduce 
the effort {i.e., the costs) associated with software development. It is hard to believe that 
the job of implementing a 64-byte buffer in hardware would be much more difficult than 
that of implementing a 40-byte buffer. Had Intel done this, we would have been spared 
months of development difficulties, during which we did not understand the reason why 
the C code did not work. 

Finally, the use of a compiled language which is highly portable (in particular a 
compiled language such as C) can help protect the investment of time and money in 
software which is otherwise threatened as obsolete hardware is replaced by improved 
hardware. In the software industry, endless conversions from one hardware system to 
a new one seem to be a permanent nuisance. The ability to take old programs and make 
them work on new' hardware simply by recompiling them is attractive. 

Another potentially useful step w^ould be to implement the controller software using 
Ada, the Department of Defense compiled language now' mandated for embedded soft- 
ware in all purchased systems. This would have the advantage that Ada programmers 
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are likely to become more and more numerous over time. This would help keep the work 
already done both current and useful. 
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APPENDIX A. DERIVATION OF DESIGN EQUATIONS FOR THE 
MATCHED FILTER 

This appendix presents derivations and proofs of results used elsewhere in this thesis. 

A. BIQUADRATIC FILTERS USING TWO OPERATIONAL AMPLIFIERS 

Figure 7 on page 27 shows the topology of a generalized biquadratic filter using two 
operational amplifiers. This topology is taken from Michael [Ref. 15]. In this figure, Y 
denotes an admittance (the reciprocal of an impedance). Michael gives ideal transfer 
functions in the s-domain from the node marked V m to the nodes marked V u V 2 , and 
f'j. We will have occasion to use the first two of these. Since Michael does not provide 
derivations for these functions, they are provided below. Note that the term ‘'ideal” 
implies the use of operational amplifiers of infinite gain. While no such operational 
amplifiers in fact exist, there do exist operational amplifiers of very large gain, and the 
approximation is practical in many circumstances, especially at the low frequencies used 
in the Yibro-acoustic Experiment (i.e., the 600 Hz tone from the Auxiliary Power Unit), 
For example, the open-loop gain of the LF-444 operational amplifier is more than 
60 dB at a frequency/ = 600 Hz. 

From the KirkofT current law, and referring to Figure 7 on page 27, we have 



W 5 + h (35) 

l-; = h~ h (36) 

/, = - / 3 . (37) 

W ; e can find the currents 7, through / 8 by applying Ohm's law. 

h = {Vx-V^)f l (38) 

/ 2 *w -V 5 )Y 2 (39) 

h-lYi-VM (40) 

h = (^2-V 3 )Y 4 (41) 

WI's-l'/.vW (42) 



72 



4=^*6 (43) 

Ii = iYis-Vm (44) 

h-VjYv (45) 

By substituting these currents into equations (35) through (37), we obtain the following 
three, independent equations. 

V\-v 5 )y 2 = {v 5 -v is )y 5 +v 5 y () (46) 

( 1 ).v - J 3 ) >7 * Y 3 r 8 + ( ^3 - v 2 ) Y 4 (47) 

({•- r 4 )}' =(r 4 - r 2 )r 3 . (48) 

Collecting these terms yields 

r 5 \Y 2 +Y 5 +Y,)=l\Y 2 +V ls Y 5 (49) 

f 3U4 + ^7 + J g) = ^2^4 + * i .\ Y 7 ( 50 ) 

C 4 (l 1 + } 3 ) = Cj } j + J 2 V 3 . (51) 

In an ideal operational amplifier, the inputs have equal voltages, so we can write 
= I' 4 = K. ■ Rewriting the equations with V i in place of \\ and l\ gives 

1 3 ( >2 + }' 5 + y 6 ) = r,r 2 + v iy Y s (52) 

^( } 4 + Yf + r g ) = v 2 r 4 + v, s y 7 (53) 

Y 3 {Y x +Y 3 )=V l Y l + V 2 Y 3 . (54) 



These equations can be readily solved by placing them in matrix form first. 



" Y 2 + y 5 + y 6 0 


Y 2 


> 3 ‘ 




>5' 


r 4 + r 7 + r 8 - r 4 


0 




= 


Y? 


r, + v 3 - > 3 




V x 




_ 0 _ 



Now interchange the positions of V 2 and 



73 



( 56 ) 



0 k 2 +k 5 +k 6 


-*a" 


X 




'Yi 


- >4 Yi+Yj+Yt 


0 




= 


Yy 


- Y 3 k, + k 3 


-n. 






_0 



Next we move row 3 to the top. 



"->3 


y 1 + r 3 


~Y t ~ 


> 2 “ 




'o' 


0 


J 2 +I 5 + *6 


-y 2 


Y 3 


= 


*s 




Yt+Y 7 +Y 8 


0 


Yx m 




_>7_ 



(57) 



Next, multiply row 1 by Y it row 3 by F 3 , and subtract the latter product from the 
former to generate a new row 3. 



>3 >1 + Y 2 - Y x ' 


Y 2 




0 


0 Y 2 + Y s + Y 6 - y 2 


y 3 


= 


15 


0 - K 3 (K 4 + Y-+ Kg)+ Y\{Y X + *j) -Y x Y a 


*'i 







Now multiply row 2 by [ - } 3 (} 4 + + }' 8 ) + + } 3 )]. row 3 by (1 \ + }'< + FJ, 

and subtract the latter product from the former to generate yet another row 3. 



o 

0 



y, + >3 - k, v 2 

y 2 + > i +Y 6 - y 2 % 

0 - y, >- 4 ( y 2 + Yy + y 6 ) + y 2 [ - y 3 ( y 4 + y , + + > 4 ( k, + y 3 )]JL . 



0 

Yy 

- y 3 y 7 (y 2 + y 5 + y 6 ) - y 5 [ - y 3 (y 4 + y- + y g ) + y 4 (y, + y 3 )] 



(59, 



From row 3, we can see that 



J\_ _ - r 3 y-(y ; + y 5 + y 6 ) - y 5 [ - y 3 (y 4 + y 7 + y 8 ) + y 4 (y, + y 3 )] 

Y/y - n f 4 ( y 2 +v 5 + y 6 ) + y 2 [ - y 3 ( > 4 +y 7 + y s ) + y 4 ( y, + y 3 ) ] 

- y 3 y 7 (y 2 + y 6 ) - y 3 y 5 y 7 + y 3 y 4 y 5 + y 3 y s y- + y 3 y 5 y g - y, y 4 y 5 - y 3 y 4 y 5 
: - y, y 4 (y 5 + y 6 ) - y, y 2 y 4 - y 2 y 3 y 4 - y 2 y 3 y 7 - y 2 y 3 y g + y, y 2 y 4 + y 2 y 3 y 4 ’ 



(60) 



( 61 ) 



Many terms in the numerator and in the denominator of this expression add to zero, 
so the transfer function is 



V\ -YMYi+YJ+YMYj-Ws 

Vjs ~ Vx > a( > 5 + Y 6 ) - Y 2 Y 3 Y- - Y 2 Y 3 Kg 
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(63) 





*1*4*5+ * 3 * ?( * 2 + ) 6 ) — Y 3 F 5 > 8 


*T.vU) 


^ 1 ^ -i( ^ 5 + *6) + ^ 2 ^ 3 ( 5 7 -j- F g ) 



Vi(s) 



K(s) 



This completes the derivation of . To derive the transfer function -p— ^-y, we 
modify equation (55) by placing the variable V 2 in the last position. 
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‘-n 


*2+>s+*6 


0 






~Ys~ 


0 


f 4 +f 7 +f 8 


- r 4 


^3 


= 


Yy 


- F, 


F| + *" 3 


*3_ 






_ 0 _ 



Proceeding as before, we multiply row 3 by - F 2 , row 1 by — Y u and subtract the 
former product from the latter to generate a new row 3. 
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"—Is i'l-i's+l’e o' 


>r 




' >5 ' 


0 

f 

y 

1 


V* 


= 


>■7 


0 l',(l's+ >5+ >*) — I j( 1 ", + >3) Ijlj 


r 2 




Ji* 5 _ 



Next multiply row 2 by [ F,(F 2 -f } 5 + F s ) - F,(F, + F 3 )] , row 3 by (F 4 + F, + F„) , 
and subtract the latter product from the former to yield a new row 3. 

- >;+>Ws 0 

0 Y. + Y- + y 8 - ) 4 

0 . 0 f 2 y 3 ( >4 + Yy + y s ) + k 4 [ Yi ( y 2 + r 5 + y 6 ) - Y 2 ( y 1 + y 3 ) ] 

y 5 

)- 

. >'i f 5 < >4 + > - + >s) - Y, [ yj( >2 + y 5 + y 6 ) - >v y, + y 3 ;] 

From row 3 we can see that 
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r 2 f, r 5 r r 4 + i- + r s ) - f, f,(F : + y 5 + r 6 ) + f 2 f-(f, + y 3 ) 

F; v y 2 y 3 { f. + f 7 + r g ) + }• y 4 { y 2 + y 5 + > 6 ) - f 2 r 4 ( f, + f 3 ) ' 



(67) 



As before, many terms in both the numerator and the denominator add to zero, so 



yjjy.+ y^+y^y.-y^y, 

>2*3(*7+ >s) + >'iF 4 (> 5 + F 6 ) 



(68) 
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It is possible, using the same method illustrated in both these cases, to develop a 

I j( s) 

transfer function ^ ^ . We have no use for this particular function in the present 
context, however, so the derivation is omitted. 

B. HIGH-PASS NOTCH FILTER 

The equation of a notch Filter is given in equation (6), repeated here. 



F(s) = - 



■(*>■ 



( 6 ) 



Michael [Ref. 151 shows how to use the generalized configuration of Figure 7 on 
page 27 to implement this function in the case where cu r = co,, which is the case for a 
symmetric notch filter. However, he does not show how to implement an asymmetrical 
notch filter, in which co f # co 2 . 

We can do so by using equation (63) and making the following choices for the 
admittances Y x through Y s . 



= Q 


(69) 




(70) 


n = q 


(71) 


II 

II 


(72) 


>6=0 


(73) 


Y n = sC b 


(74) 


y *~q p 


(75) 
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(77) 



Proof 



V, 

TZ 



r r i 2 r r 2 QG 2 

C a G + s C a C b — — 



,v QG ! + s z C„C^ + jC a Q-^- 
VP 

*> + (-£-)> £i- 

' Q C C b Q, 



a ( — 


V . / JL y 


\ C b Q, 


j s+ UJ 


'ti)1 




2,1 G 


L , / JL 1= 


1 \ CtQp 


r\cj 


5 2 +.W^l-( 


-ttf)] 



(78) 






Using resistance values instead of conductance values in equations (76) and (77), 
we get 



(79) 




and 
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(80) 




C. LOW-PASS NOTCH FILTER 

To get a low-pass notch filter, we use equation (68) and pick admittances as follows: 
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where we pick 
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Converting equations ' S6> and (S“) to use resistances instead of conductances, we 



get the design equations 
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D. A SECOND-ORDER, LOW-PASS FILTER USING ONLY ONE 
OPERATIONAL AMPLIFIER 

Figure 14 on page 36 is the schematic of a generalized second-order. low 
The general equation of a low-pass biquadratic filter is given by [Ref. 12 : p. 
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This transfer function can be realized by the schematic in Figure 14 on 
we make the following choices for the components. 

1 
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From equation (94), 
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(99) 



V a ~ V n 
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We can manipulate this equation to obtain the transfer function. 
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To design a filter to provide desired values of and Q p , use the design equations 
which can easily be derived from the above equations. 

1 . Pick C 2 arbitrarily. 

2. Let Q = 

3. Let Ri = 



4 C 2 Qj. 

R 2 = R = 



1 



£ oJC,C 2 
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APPENDIX B. CHOICE OF A SOFTWARE DEVELOPMENT SYSTEM 

A. Z-80 ASSEMBLY LANGUAGE 

The Vibro-acoustic Experiment has a fairly long history. Long before the author 
became associated with the project, two distinct choices for a software environment^ 
had already been made. Early in the project we used Z-80 assembly language for pro- 
gramming the controller. An ALTOS eight-bit microcomputer running under Digital 
Research Corporation’s Control Program for Microcomputers (CP, M) was available. 
It included a Z-SO assembler (MSO), a librarian (LIBSO) and a linker (L80). However, 
the turnover in student personnel is rather high at any educational institution; the Naval 
Postgraduate School is no exception. Assembly language is often not the best choice for 
a project whose participants do not remain for the life of the project, since assembly 
language is not widely known, is not easy to learn, and is highly dependent on the ar- 
chitecture of the machine in which the final program is to operate. Many different ar- 
chitectures exist, and most machines have unique architectures. Even those who know 
how to program with assembly language often are averse to expending the vast amounts 
of time required to use it for any but the most trivial programs. 

B. CP/M AND TOOLWORKS C 

As a consequence of these facts, one of the early participants in the project suc- 
cessfully promoted a switch away from Z-80 assembly language to the C programming 
language. This high-level language includes powerful operators which make it easy to 
manipulate the bits within the bytes of the computer's memory, and so it can do almost 
anything that can be done in assembly language. The same ALTOS CP M system 
happened to have Toolwork’s C compiler on it, and so we used it. 

When the author joined the project, little progress had been made in actually writing 
the control program. With Captain Frank Mazur, L'SMC, and Captain Ron Byrnes, 
USA, the author wrote much of the control program on the ALTOS under CP, M- using 
the Toolwork’s C compiler. 

15 The term software environment refers to the computer, the operating system, the program- 
ming language, and all related software and hardware tools used to program a computer. The 
computer on which the development of software is done need not necessarily be the same one as 
that in which the completed program will reside and be executed. In the case of the Vibro-acoustic 
Experiment, it is not the same computer. 
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Doing so proved to be a frustrating business. The ALTOS was equipped with two 
eight-inch, single-sided, single-density, floppy diskette drives. These could contain only 
around 250 Kbytes of data. One drive had to contain a copy of the CP M operating 
system at nearly all times. The ALTOS was quite slow by present standards; it was not 
uncommon for a compilation to take five minutes. Due to the limited disk space avail- 
able, the output of the compiler (an 8080 assembly language source filei6 ) had to be 
transferred to another diskette before assembly could proceed. Assembly typically con- 
sumed a further five minutes. The library program was quite inconvenient to use, but 
once the executable modules had been loaded successfully into a library, linking was 
straightforward. This was a comparatively quick two-minute process. 

Our EPROM writing program was on an IBM-PC using Microsoft’s Disk Operating 
System (MS DOS). Furthermore, that machine had only 5 1 4 inch diskettes. So we 
took our eight-inch floppies to a Zenith Z-100 that had both sizes of drives, where we 
converted the CP M file containing executable code into an MS DOS file on a 5 1 4 inch 
diskette. 

Finally, we loaded the executable program from the diskette into the 
EPROM-writing program and created the firmware. 

C. MS/DOS AND UNIWARE C 

It should not have taken us too long to tire of this agonizing procedure. In fact, it 
was over a year before we began seriously to search for an improvement in the form of 
a cross-compiler. We wanted a C-language compiler which would operate on an IBM 
PC using MS DOS, and which would generate Z-SO object code. Several were available. 
We selected the LniWare C Compiler package from Software Development Systems. 
3110 Woodcreek Drive. Downers Grove, IL 60515. This product is a complete software 
development system. It includes a C compiler which produces Z-80 assembly code, a 
Z-80 assembler, a library manager to store object modules in a single MS DOS library' 
file, a linker to convert a collection of object modules into an executable file, and a large 
collection of utility programs, useful for listing files, converting files from one format to 
another, and so on. The compiler implements the complete C language defined by 

16 The Toolwork’s C compiler generates 8080 assembly language source code. The NSC800 
on the controller board can execute Z-80 code, a subset of the NSC800 instruction set, and the 8080 
instruction set, which is itself a subset of the Z-80 instruction set. We had an assembler for Z-80 
and 8080 code. We needed two Z-80 instructions not available in the 8080 instruction set. So we 
embedded Z-80 machine code in the 8080 assembly source created by the C compiler and executed 
the resultant module with an NSC800. It really was at least as complicated as it sounds! 
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Kernighan and Ritchie [Ref. 16]. It also includes enhancements similar, but not identi- 
cal, to those proposed by the American National Standards Institute (ANSI). 

It took a little time to convert from the old to the new system, but the results were 
well worth the effort. Because the performance of the IBM System 2 Model SO on which 
we run this system is so much greater than that of the Altos, we are able to generate a 
new version of the controller program in much less time. The use of MS DOS also has 
provided significant benefits. We have made extensive use of hierarchical file directories 
in order to group files in a logical manner. We also use MS DOS batch files to minimize 
the amount of memory work necessary to execute such programs as the compiler and 
the linker. 

The documentation supplied with the L'niWare system [Ref. 17] is excellent. Unlike 
most C compilers, this one is not meant to produce executable code running under an 
operating system. For this reason, much of the standard library supplied with other C 
compilers is not applicable, and is not supplied. In particular, no library functions are 
provided to perform disk input or output. However, common output formatting rou- 
tines such as printfQ are included. 

D. GENERATION OF FIRMWARE IN EPROM 

We use the Intel program pcpp to load the completely linked program into EPROM. 
The L'niWare software can create a symbol table showing what should go where. Armed 
with this list, one can load, install, and test the new version of the program in short or- 
der. 

Details on the operation of this program are presented in Section 2. Getting the 
Executable Program into EPROM on page 146. 
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APPENDIX C. HOW THE UNIWARE SOFTWARE USES THE 
COMPUTER MEMORY 



The L'niWare software regards memory as comprised of a number of named regions. 
The C compiler itself creates five of these [Ref. 17: Compiler section, p.3]. These are the 
regions code, string, const, data, and ram. There are three further software regions: 
reset, mbrkram, and stack. The purpose of each region is described below. The linker 
treats each region as a unit and places its contents in memory in contiguous storage lo- 
cations. It decides how to do this based on instructions in the file 
\vibro\contrlr\object\spec. The order in which these regions appear in memory is speci- 
fied in this file, and reflected both in Figure 19 on page 44, and in the order in which 
they are described here. 

reset The Z-SO architecture specifies that the program code stored at memory 
location 0\0000 be executed whenever the microprocessor receives power 
or a hardware reset occurs. The reset region contains an appropriate 
start-up program. This program does the following: 

1. It initializes the stack pointer to 0x0000. Whenever an item is stored in 
the stack, the stack pointer is first decremented. Thus, the stack pointer 
will initially be decremented to OxflTf. the first location in the stack, and 
will continue to grow downward in memory from this point. 

2. It initializes the interrupt tables in such a manner that, should a spurious 
interrupt occur, the control program will restart from the beginning. It 
would be preferable to resume execution by simply returning from the 
interrupt. This would raise the unacceptable possibility, however, of an 
indefinite suspension of the execution of the program if some unpredict- 
able cause led to the problem. While restarting has the disadvantage of 
totally disrupting matters, its compelling advantage is that execution re- 
sumes from a known state, barring a complete catastrophe. 

code This region contains all program instructions generated by C and assembly 
language source code. It includes code to do the following things: 

1. Program variables must be in RAM to be altered. In the C program- 
ming language it is possible to assign initial values to these variables at 
the time a program is compiled. These values must be placed in 
EPROM, since otherwise they would be lost. One of the routines in the 
code region is invoked at start-up time to copy initialized variables from 
their permanent locations in region data in EPROM into temporary lo- 
cations in RAM. Thus in Figure 19 on page 44 region data appears in 
two locations, both in EPROM and in RAM. 



86 



2. The definition of the C programming language specifies that static^ and 
external! 8 variables which have no initial value specified in their decla- 
rations must be initialized by the compiler to the value 0 [Ref 16; p.l9S]. 
One of the routines in the code region is invoked at start-up time to put 
zeros in all RAM locations in region ram. 

3. Another routine which is invoked at start-up time calls the C program 
main(). This is the highest level program in C. It calls subordinate 
routines to operate the controller and run the experiment itself. 

string Whenever the compiler finds a quoted character string in the source code, 
it places it in the string region. Since strings are treated as constants, they 
can be kept in EPROM. 19 

const Variables declared as const are regarded by the compiler as invariant, or 
constant, so it is reasonable to place them in EPROM. 

data This region contains variables whose initial values were specified at the time 
of compilation. These values are placed in EPROM by the linker so that 
they will not be lost when power is removed from the controller. However, 
variables must be in RAM when the program executes. During the start-up 
procedure, they are copied into RAM. 

ram This region contains variables whose initial values were not specified at the 
time of compilation. These are initialized to 0 at the time the program is 
first invoked, as specified in Kernighan and Ritchie [Ref. 16 : p. 198]. 

mbrkram The UniWare C compiler provides a function mbrk() to permit a program 
to request storage at run time (i.e.. dynamically). The mbrkram region 
provides mbrk() with the storage it needs. 

stack The program stack is located here, at the top of memory. 

The linker ensures that items within a region are stored contiguously. The compiler 
decides where to put these partitions in memory by examining a memory map provided 
in the specification file \vibro\contrlr\object\spec, listed in Section A. Filename spec on 
page 150. The format of this file is described in [Ref. 17; Link Editor Section, p. 7]. 

The memory map specifies that reset be loaded at address 0x0000, that the stack 
grow down in memory from address Oxfilf, that EPROM is available from addresses 
0x0000 through 0x5fiT, and that RAM is available starting from address OxeOOO through 
OxfiTT. 



1 7 Static variables retain their values even after the program which declared them finishes ex- 
ecuting. 

1 8 External variables are declared in some module other than the one in which a program using 
these variables is defined. 

19 In general, to modify strings a programmer must first place a copy of them into a variable. 
Dynamic variables are always located in RAM, since their contents are changeable. 
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APPENDIX D. HIERARCHICAL ORGANIZATION OF SOFTWARE 
FILES 



All the software to control the Vibro-Acoustic Experiment is located in the file hi- 
erarchy illustrated in Figure 35 on page 89. Following is a description of the contents 
of each of these subdirectories. 

A. SUBDIRECTORY \VIBRO\CONTRLR\HEADERS 

This subdirectory contains header files for the C language source code. The header 
files allow numeric constants which are used in creating the program to be specified 
symbolically. By avoiding the use of “magic” numbers in the source code, the code is 
rendered much more readily understood. The header files also contain external declara- 
tions of the functions and variables contained within a module. Whenever one module 
needs to use the functions or variables of a different module, it can obtain correct dec- 
larations of them by including the appropriate header file using the C programming 
language ^include directive. 

B. SUBDIRECTORY \\TBRO\CONTRLR\CSOURCE 

This subdirectory contains C language source code for the parts of the controller 
program written in the C programming language.20 

C. SUBDIRECTORY \\TBRO\CONTRLR\ASMSOURC 

This subdirector}- contains Z-80 assembly language source code. A few of the lowest 
level routines in the controller software have been written in assembly language, but only 
when there was no apparent way to write them in C (e.g.,input(), output()), or when the 
C compiler couldn’t generate code which would execute rapidly enough (e.g., bubread() 
and bub>vrite()). 

D. SUBDIRECTORY \VIBRO\CONTRLR\BATCH 

This subdirectory contains a number of MS/DOS “batch” files. These contain se- 
quences of commands which make it easier to compile programs, print listings of the 
source code, link object modules, and load executable modules into EPROMs. 



20 This comprises most of the controller software. 




Figure 35. Hierarchical Organization of Softnaie Files: The software files are 

grouped into several different sub-directories to facilitate finding and 
managing them. 

E. SUBDIRECTORY \VIBRO\CONTRLR\LlST 

This subdiiectory contains output listings produced cither by the C compiler or by 
the Z-80 assembler. -1 Those created from C source code include that code in the form 
of comments to the Z-80 assembler. They are stored in this subdiiectory only as a 
matter of convenience, in order that they not clutter up the directory listing of the sub- 
directories containing the source code. 

F. SUBDIRECTORY \VIBRO\CONTRLR\OBJECT 

This subdirectory contains object modules produced either by the C compiler or by 
the Z-80 assembler. They arc stored in this subdirectory only as a matter of conven- 
ience, in order that they not clutter up the subdirectories containing the source code. 



21 Those produced by the C compiler are actually assembly language listings produced by the 
Z-80 assembler. 1 he latter is called by the C compiler. 
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This subdirectory also contains the link specification file spec. This file provides the 
linker with information needed to decide where the various regions of the program must 
be loaded. A number of global variables are set by this file at link time. 

For details on how to use a link specification file, see the discussion in 
[Ref. 17: Link Editor Section, p. 7], 
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APPENDIX E. SUBROUTINES, IN ALPHABETICAL ORDER BY NAME 



Table 8. SUBROUTINE INDEX: This table shows the names of the MS DOS 



files in which each subroutine can be found. Subroutines are listed al- 
labetically by name. 



SUBROUTINE 


SOURCE 

FILE 


PURPOSE 


ad_readQ 


expmnt.c 


Gets a character of data from the Analog- 
to-digital (A D) Converter. 


adtoint() 


expmnt.c 


Converts a character of raw data from the 
Analog-to-digital (A D) Converter into an 
integer format with the more meaningful 
units of volts or degrees kelvin. 


a!ter_pageOf) 


expmnt.c 


Permits the user to alter the contents of page 
0 of the bubble memory. This is required in 
initializing the experiment. 


allow_ctrl_interrupts() 


inout.c 


Processes the special characters CTRL S and 
CTRL Y when read from the keyboard. 
CTRL S is a toggle switch. The first time it 
is pressed, the display halts. The second time 
it is pressed, the display resumes. Subse- 
quently its function alternates between these 
two. CTRL Y invokes the diagnostic sub- 
system. 


atoh() 


convert.c 


Converts an ASCII string representation of 
a hexadecimal byte into the corresponding 
hexadecimal byte. For example, the string 
“a 3" is converted to the byte value 0xa3. 


atohexint() 


convert.c 


Converts a four-byte ASCII string repres- 
enting a two-byte hexadecimal word into the 
corresponding hexadecimal word. For ex- 
ample. the string “a34b” is converted to the 
word 0xa34b. 


atoiO 


convert.c 


Converts a string representing a decimal in- 
teger into the corresponding integer. This 
subroutine is from Bilofsky [Ref. 1 8]. 


bad_idea_to_record() 


expmnt.c 


This routine is used in the abridged exper- 
iment to prevent record mode from being re- 
started after a power fault. Without this 
safeguard, perfectly good data recorded dur- 
ing launch might be erased. 
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baro_s>vitch() 


expmnt.c 


Checks to see if the barometric switches have 
been activated yet. If so, launch must have 
occurred and an appropriate log entry is 
made. 


bcd_asc() 


convert.c 


Converts a BCD byte to the corresponding 
character string representation. For exam- 
ple, 0x17 is converted to “17”. 


bcd_int() 


convert.c 


Converts a one-byte BCD number to integer 
Format. 


bpageset() 


bubble.c 


Loads the live parametric registers in the 
bubble memory 7 controller. Most of these 
never change. Two, however, do change of- 
ten. These two specify the page of bubble 
memory where transfers of data begin. Call 
this function prior to any operation per- 
forming input from or output to the bubble 
memory to ensure the parameters are cor- 
rectly specified. 


bubcmdnienu() 


bubble.c 


Displays a menu of low-level bubble memory- 
controller commands. These are useful in 
testing the bubble memory for proper oper- 
ation. 


bubinit() 


bubble.c 


Initializes the bubble memory prior to its 
being used. This initialization must always 
be done after power is applied and before 
input and output operations begin. 


bubio() 


bubble.c 


Performs input from and output to the bub- 
ble memory. 


bubmenu() 


bubble.c 


Provides a menu of functions permitting the 
user to perform operations with the bubble 
memory. These operations include: 

1 . applying and removing power, 

2. initialization, 

3. input, 

4. output and 

5. reading 

the status of the bubble memory. 


bub_off() 


bubble.c 


Removes power from the bubble memory. 


bub_onf) 


bubble.c 


Applies power to the bubble memory 7 . 
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bubread() 


bubnv.s 


Takes care of the actual transfer of data from 
the bubble memory to the controller memory 
during a read. This routine was written in 
assembly language in order to achieve a data 
transfer rate of 16 K bytes per second im- 
posed by the bubble memory hardware. 


bub«rite() 


bubnv.s 


Takes care of the actual transfer of data to 
the bubble memory from the controller 
memory during a write. This routine was 
written in assembly language in order to 
achieve a data transfer rate of 16 K bytes per 
second imposed by the bubble memory 
hardware. 


bub\fer() 


bubr^.s 


Part of the sequence of steps necessary to 
initialize the bubble memory entails trans- 
ferring the byte OxfF to the bubble memory 
40 times. This routine does this. The rou- 
tine is written in assembly language for 
speed, but is called in the same manner as a 
C routine. 


checkprtQ 


expmnt.c 


Checks to see whether or not there is a ter- 
minal connected to the RS-232C serial inter- 
face port. 


clockint() 


clock.c 


Dates and times in the real time clock are 
stored in BCD format. This routine converts 
them to integer format to make it convenient 
to perform arithmetic with them. Thus, fu- 
ture dates and times can be computed. 


clockreadO 


clock.c 


Reads the current date and time from the 
real time clock. 


clockcompareO 


clock.c 


Compares two clock times to see which one 
is later than the other. 


clockset() 


clock.c 


Sets the current date and time in the real 
time clock according to values specified by 
the user. 


cIocksumQ 


c!ock.c 


Adds two dates and times together to 
produce a new date and time. In practice, 
one uses this to calculate a future date and 
time from the current date and time and 
some desired delay (e.g., 15 minutes). 


colder_than() 


expmnt.c 


Returns the value TRUE if the bubble 
memory’s temperature is below the temper- 
ature given in the argument to the function, 
FALSE otherwise. 


ctoh() 


convert.c 


Converts a single character to its 
hexadecimal ASCII string representation. 
For example. 0xa3 is converted to “a3”. 
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delayQ 


delay.s 


Provides a software-driven time delay in in- 
crements of 10 ms. Written in assembly 
language, but used like a C language routine. 
Adapted from a program by Mr. David 
Rigmaiden of the Naval Postgraduate 
School. 


display_pageO() 


expmnt.c 


Displays the contents of page 0 in a readable 
format. 


display_data_page() 


expmnt.c 


Displays the contents of any page in the 
bubble memory in a readable format. It will 
not successfully display page 0. Use 
display_pageO() for this purpose. 


do_sweep() 


expmnt.c 


Causes the sweep phase of the experiment to 
be performed. 


dumpO 


inout.c 


Produces a hexadecimal and ASCII dump 
of any desired region of memory. 


duinp_clock() 


clock.c 


Display the date and time on the terminal. 


dumpJclockO 


clock.c 


Display the date and time on the terminal. 
This differs from dump_clock() in that the 
dates and times it uses are integers, not Bi- 
nary Coded Decimal (BCD) numbers. 


echo() 


inout.c 


Sends a single character to the terminal. 


expmnt() 


expmnt.c 


Causes the Yibro-acoustic Experiment to be 
performed. 


fputc() 


fputc.c 


The UNI WARE compiler provides the 
standard C output routine printf<) to provide 
output to the standard output device. How- 
ever. this routine requires the user to provide 
a routine fputc() to handle the output of a 
single character to any arbitrary device. We 
only support output by fputc() to the 
RS-232C terminal, so this routine is specific 
to that device. The routine will not output 
a character if, upon checking, it finds there 
is no terminal attached to the serial interface 
port. Thus, when the experiment is operat- 
ing, calls to printf() are of no effect unless 
there is a terminal connected. 


gethex() 


inout.c 


Inputs a string representation of a two-digit 
hexadecimal number from the terminal and 
converts it to hexadecimal format. For ex- 
ample, “3a’' is converted to 0x3a. 


gethexint() 


inout.c 


Gets a four-digit hexadecimal number in 
string format from the terminal and converts 
it to a hexadecimal word. For example, 
“3ab2" is converted to 0\3ab2. 
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getint() 


inout.c 


Inputs a string representation of a decimal 
integer from the terminal and converts it to 
integer format. For example, “352” is con- 
verted to 352. 


getpagenoO 


inout.c 


Asks the user for a page number in bubble 
memory. 


get_time() 


clock.c 


Obtain a valid date and time from the user. 


inithardv\are() 


initial.c 


Initializes the six ports on NSC810A =1 and 
-2. 


input() 


newio.s 


Inputs a character from a port. Written in 
assembly language, but used like a C lan- 
guage routine. 


int_bcdQ 


convert.c 


Converts an integer in the range 0 through 
99 to BCD format. 


issububcmd() 


bubble. c 


Issues commands to the bubble memory 
controller and analyzes the status codes 
which result. In many cases, it will attempt 
to issue a command repeatedly if there is 
some failure, doing this up to a specified 
number of times. This routine is written in 
C and is not fast enough to handle the read 
and write commands. Use bubread(J and 
bubwrite( ) for these. 


itoa() 


convert.c 


Converts an integer to an ASCII string rep- 
resentation. This subroutine is from Bilofskv 
[Ref. IS}. 


listen() 


expmnt.c 


Listens for the Auxiliary Power Units 
(APUs) to be activated. It also monitors the 
Vibration-activated Launch Detector and 
the Barometric Pressure Switches to see if a 
launch has occurred without detection of the 
activation of the APUs. 


logevent() 


expmnt.c 


Makes entries into the event log stored in the 
bubble memory. 


log_menu() 


expmnt.c 


Displays a menu to provide for conveniently 
changing the contents of bubble memory. 
This is essential for properly initiating the 
experiment. 


look_aheadO 


inout.c 


This program can see whether a character 
has been input from the keyboard without 
disturbing the input buffer. 


mainQ 


main.c 


First C language subroutine to get control 
after start-up. Decides whether to invoke 
the menu-driven diagnostic routines or to 
run the Vibro-acoustic Experiment. 
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mbrk() 


mbrk.s 


Implements the C language standard library 
function mbrk(). This function was provided 
with the Uniware C Compiler. 


memory_dumpO 


main.c 


Asks the user for an address in memory and 
the number of bytes he wants to see dis- 
played. It then provides a hexadecimal and 
ASCII display of the contents of the selected 
area of memory on the terminal. 


menu() 


main.c 


Displays the first in a hierarchy of menus 
permitting the user to test subsystems of the 
Vibro-acoustic Experiment individually. 


monitor_heatersO 


expmnt.c 


Operates the heaters if the temperature of 
the bubble memory is too cold. If the tem- 
perature is too hot, it shuts the heaters off. 
Otherwise it leaves the heaters alone. 


outputQ 


newio.s 


Outputs a byte to a port. Written in assem- 
bly language, but used like a C language 
routine. 


portdumpO 


inout.c 


Outputs a string to the terminal. 


post_launch() 


expmnt.c 


Conducts routine monitoring of events upon 
the completion of the Vibro-acoustic Exper- 
iment. These functions continue until the 
Space Shuttle returns to earth, or until the 
10V bus no longer carries sufficient voltage 
for safe operation of the bubble memories. 

In the latter case, the experiment stops all 
operations. 


power_status() 


poner.c 


Inputs the one-byte status code from the 
power relay subsystem. 


pow er_w rite() 


power.c 


Sends a one-byte command code to the 
power relay subsystem. 


pw rcnt() 


power.c 


A menu program which let's the user read 
the status code from the power relay subsys- 
tem or send commands to it. 


rdstatregO 


bubble.c 


Reads the status register of the bubble 
memory controller. 


record() 


expmnt.c 


Performs the record phase of the abridged 
experiment. 


rtcO 


clock.c 


A menu routine allowing the user to set or 
read the clock, and to test the time-out fea- 
ture (see testtimeout() in this table). 


short_experiment() 


expmnt.c 


Performs the abridged Vibro-acoustic Ex- 
periment. 
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sho»bubbuff() 


bubble.c 


A buffer exists in the controller’s memory to 
hold a copy of data transferred to or from 
the bubble memory. This routine displays 
the contents of that buffer either in ASCII 
characters or hexadecimal. 


show_event() 


expmnt.c 


Converts an event code into an intelligible 
message which it then displays on the termi- 
nal. 


show_\vaketime() 


clock.c 


Displays the date and time when a time-out 
will end. 


shut_do»nf) 


expmnt.c 


Removes power from any subsystems which 
presently have power. It makes a log entry 
for each such case. 


shut_don n_no_log() 


expmnt.c 


Removes power from any subsystems which 
presently have power. It makes no log entry 
of its actions. 


ssdrmode() 


expmnt.c 


Issues commands to the Solid State Data 
Recorder (SSDR) to enter various modes of 
operation. 


ssdr_status() 


expmnt.c 


Obtains the status code from the Solid State 
Data Recorder 1 SSDR). 


termini ) 


inout.c 


Inputs a single character from the terminal. 


testinput() 


inout.c 


Asks the user for a hexadecimal port address, 
reads that port and displays the data read 
from that port. 


testio() 


main.c 


This routine permits the user to perform in- 
put from and output to any port in the sys- 
tem. By “port" we mean here an address in 
the input and output space. 


testoutput() 


inout.c 


Asks the user for a hexadecimal port address 
and a hexadecimal byte to be sent to the 
port, and sends it there. 


testpattern() 


bubble.c 


A buffer exists in the controller's memory to 
hold a copy of data transferred to or from 
the bubble memory. This routine permits 
the user to modify the contents of that 
buffer. 


testtimeoutQ 


clock.c 


Lets the user test the time-out feature. For 
example, he can request a delay of 15 sec- 
onds. During this delay, the control pro- 
gram will not respond to input. At the end 
of this period, it will display the current date 
and time. 
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timeoutQ 


clock.c 


In one mode of operation, this function 
computes a “wake-up” time based on the 
current time and a specified delay. In an- 
other mode, it checks to see if a “wake-up” 
time computed earlier has arrived or not. 


tolowerO 


convert.c 


Converts upper case characters to lower 
case. Non-alphabetic characters are not 
changed. This subroutine is from Bilofskv 
[Ref. 18). 


uitohO 


convert .c 


Converts an unsigned integer to the corre- 
sponding hexadecimal ASCII string repre- 
sentation. For example, 45 is converted to 
“2D” 


versiont) 


version.c 


Displays the current version number of the 
control program on the terminal. 


voltages_lo>\() 


expinnt.c 


Checks the 10V bus. If the voltage has fallen 
too low, this function returns the value 
TRUE; otherwise it returns the value 
FALSE. 


»e_launched() 


expmnt.c 


Checks for any indications of a launch. 
These can come from the Vibration-activated 
Launch Detector or from the Barometric 
Pressure Switches. 
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APPENDIX F. SUBROUTINES, IN ALPHABETICAL ORDER WITHIN 
EACH MODULE 



Table 9. MS/DOS FILE INDEX: This table shows the names of the files in the 



MS DOS files. Subroutines are listed alphabetically by name within each 
file group. 



SOURCE 

FILE 


SUBROUTINE 


PURPOSE 


bubble. c 


bpagesetO 


Loads the five parametric registers in the 
bubble memory controller. Most of these 
never change. Two. however, do change of- 
ten. These two specify the page of bubble 
memory where transfers of data begin. Call 
this function prior to any operation per- 
forming input from or output to the bubble 
memory to ensure the parameters are cor- 
rectly specified. 


bubble.c 


bubcmdmenu(J 


Displays a menu of low-level bubble memory 
controller commands. These are useful in 
testing the bubble memory for proper oper- 
ation. 


bubble.c 


, bubinitO 


Initializes the bubble memory prior to its 
being used. This initialization must always 
be done after power is applied and before 
input and output operations begin. 


bubble.c 


bubio() 


Performs input from and output to the bub- 
ble memory. 


bubble.c 


bubmenu() 


Provides a menu of functions permitting the 
user to perform operations with the bubble 
memory. These operations include: 

1. applying and removing power, 

2. initialization, 

3. input, 

4. output and 

5. reading 

the status of the bubble memory. 


bubble.c 


bub_off( ) 


Removes power from the bubble memory. 


bubble.c 


bub_on() 


Applies power to the bubble memory. 
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bubble.c 


issububcmd() 


Issues commands to the bubble memory 
controller and analyzes the status codes 
which result. In many cases, it will attempt 
to issue a command repeatedly if there is 
some failure, doing this up to a specified 
number of times. This routine is written in 
C and is not fast enough to handle the read 
and write commands. Use bubread() and 
bubnrite() for these. 


bubble.c 


rdstatreg() 


Reads the status register of the bubble 
memory controller. 


bubble.c 


sho^bubbuff() 


A buffer exists in the controller's memory’ to 
hold a copy of data transferred to or from 
the bubble memory. This routine displays 
the contents of that buffer either in ASCII 
characters or hexadecimal. 


bubble.c 


testpattern() 


A buffer exists in the controller's memory to 
hold a copy of data transferred to or from 
the bubble memory. This routine permits 
the user to modify the contents of that 
buffer. 


bubr\>.s 


bubread() 


Takes care of the actual transfer of data from 
the bubble memory to the controller memory 
during a read. This routine was written in 
assembly language in order to achieve a data 
transfer rate of 16 K bytes per second im- 
posed by the bubble memory hardware. 


bubn\.s 


bubwrite() 


Takes care of the actual transfer of data to 
the bubble memory from the controller 
memory during a write. This routine was 
written in assembly language in order to 
achieve a data transfer rate of 16 K bytes per 
second imposed by the bubble memory 
hardware. 


bubrw.s 


bubxfer() 


Part of the sequence of steps necessary to 
initialize the bubble memory entails trans- 
ferring the byte OxPf to the bubble memory 
40 times. This routine does this. The rou- 
tine is written in assembly language for 
speed, but is called in the same manner as a 
C routine. 


clock.c 


clockcompare() 


Compares two clock times to see which one 
is later than the other. 


clock.c 


clockintQ 


Dates and times in the real time clock are 
stored in BCD format. This routine converts 
them to integer format to make it convenient 
to perform arithmetic with them. Thus, fu- 
ture dates and times can be computed. 
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clock.c 


clockread() 


Reads the current date and time from the 
real time clock. 


clock.c 


clocksetO 


Sets the current date and time in the real 
time clock according to values specified by 
the user. 


clock.c 


clocksum() 


Adds two dates and times together to 
produce a new date and time. In practice, 
one uses this to calculate a future date and 
time from the current date and time and 
some desired delay (e.g., 15 minutes'). 


clock.c 


dump_clock() 


Display the date and time on the terminal. 


clock.c 


dump_iclock() 


Display the date and time on the terminal. 
This differs from dump_clock() in that the 
dates and times it uses are integers, not Bi- 
nary Coded Decimal (BCD) numbers. 


clock.c 


get_time() 


Obtain a valid date and time from the user. 


clock.c 


rtc() 


A menu routine allowing the user to set or 
read the clock, and to test the time-out fea- 
ture (see testtimeoutO in this table). 


clock.c 


shou_'\aketime() 


Displays the date and time when a time-out 
will end. 


clock.c 


testtimeoutO 


Lets the user test the time-out feature. For 
example, he can request a delay of 15 sec- 
onds. During this delay, the control pro- 
gram will not respond to input. At the end 
of this period, it will display the current date 
and time. 


clock.c 


timeout() 


In one mode of operation, this function 
computes a “wake-up” time based on the 
current time and a specified delay. In an- 
other mode, it checks to see if a “wake-up" 
time computed earlier has arrived or not. 


convert.c 


atoh() 


Converts an ASCII string representation of 
a hexadecimal byte into the corresponding 
hexadecimal byte. For example, the string 
“a3” is converted to the byte value 0xa3. 


convert.c 


atohexintO 


Converts a four-byte ASCII string repres- 
enting a two-byte hexadecimal word into the 
corresponding hexadecimal word. For ex- 
ample, the string “a34b” is converted to the 
word 0xa34b. 


convert.c 


atoi() 


Converts a string representing a decimal in- 
teger into the corresponding integer. This 
subroutine is from Bilofsky [Ref. IS]. 
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convert.c 


bcd_asc() 


Converts a BCD byte to the corresponding 
character string representation. For exam- 
ple, 0\17 is converted to “17”. 


convert.c 


bcd_int() 


Converts a one-byte BCD number to integer 
format. 


convert.c 


ctoh() 


Converts a single character to its 
hexadecimal ASCII string representation. 
For example, 0xa3 is converted to “a3”. 


convert.c 


int_bcd() 


Converts an integer in the range 0 through 
99 to BCD format. 


convert.c 


itoa() 


Converts an integer to an ASCII string rep- 
resentation. This subroutine is from Bilofskv 
[Ref. IS]. 


convert.c 


tolo\\er() 


Converts upper case characters to lower 
case. Non-alphabetic characters are not 
changed. This subroutine is from Bilofskv 
[Ref. 18]. 


convert.c 


uitoh() 


Converts an unsigned integer to the corre- 
sponding hexadecimal ASCII string repre- 
sentation. For example. 45 is converted to 
“2D" 


delay.s 


delayO 


Provides a software-driven time delay in in- 
crements of 10 ms. Written in assembly 
language, but used like a C language routine. 
Adapted from a program by Mr. David 
Rigmaiden of the Naval Postgraduate 
School. 


expmnt.c 


ad_read() 


Gets a character of data from the Analog- 
to-digital (A D) Converter. 


expmnt.c 


adtoint() 


Converts a character of raw data from the 
Analog-to-digital (A D) Converter into an 
integer format with the more meaningful 
units of volts or degrees kelvin. 


expmnt.c 


alter_pageO() 


Permits the user to alter the contents of page 
0 of the bubble memory. This is required in 
initializing the experiment. 


expmnt.c 


bad_idea_to_record() 


This routine is used in the abridged exper- 
iment to prevent record mode from being re- 
started after a power fault. Without this 
safeguard, perfectly good data recorded dur- 
ing launch might be erased. 


expmnt.c 


baro_switch() 


Checks to see if the barometric switches have 
been activated yet. If so, launch must have 
occurred and an appropriate log entry is 
made. 
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expmnt.c 


checkprt() 


Checks to see whether or not there is a ter- 
minal connected to the RS-232C serial inter- 
face port. 


expmnt.c 


colder_than() 


Returns the value TRUE if the bubble 
memory’s temperature is below the temper- 
ature given in the argument to the function, 
FALSE otherwise. 


expmnt.c 


displav_data_page() 


Displays the contents of any page in the 
bubble memory in a readable format. It will 
not successfully display page 0. Use 
display_pageO() for this purpose. 


expmnt.c 


display_pageO() 


Displays the contents of page 0 in a readable 
format. 


expmnt.c 


do_s«eep() 


Causes the sweep phase of the experiment to 
be performed. 


expmnt.c 


expinnty 


Causes the Vibro-acoustic Experiment to be 
performed. 


expmnt.c 


listenO 


Listens for the Auxiliary Power Units 
(APUs) to be activated. It also monitors the 
Vibration-activated Launch Detector and 
the Barometric Pressure Switches to see if a 
launch has occurred without detection of the 
activation of the APUs. 


expmnt.c 


logeventO 


Makes entries into the event log stored in the 
bubble memorv. 


expmnt.c 


log_menu() 


Displays a menu to provide for conveniently 
changing the contents of bubble memory. 
This is essential for properly initiating the 
experiment. 


expmnt.c 


monitor_heaters() 


Operates the heaters if the temperature of 
the bubble memory is too cold. If the tem- 
perature is too hot, it shuts the heaters off. 
Otherwise it leaves the heaters alone. 


expmnt.c 


post_launch() 


Conducts routine monitoring of events upon 
the completion of the Vibro-acoustic Exper- 
iment. These functions continue until the 
Space Shuttle returns to earth, or until the 
10V bus no longer carries sufficient voltage 
for safe operation of the bubble memories. 

In the latter case, the experiment stops all 
operations. 


expmnt.c 


record() 


Performs the record phase of the abridged 
experiment. 


expmnt.c 


short_experiment() 


Performs the abridged Vibro-acoustic Ex- 
periment. 
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expmnt.c 


shon_event() 


Converts an event code into an intelligible 
message which it then displays on the termi- 
nal. 


expmnt.c 


shut_do\vn() 


Removes power from any subsystems which 
presently have power. It makes a log entry 
for each such case. 


expmnt.c 


shut_down_no_log() 


Removes power from any subsystems which 
presently have power. It makes no log entry 
of its actions. 


expmnt.c 


ssdrmode() 


Issues commands to the Solid State Data 
Recorder (SSDR) to enter various modes of 
operation. 


expmnt.c 


ssdr_status() 


Obtains the status code from the Solid State 
Data Recorder (SSDR). 


expmnt.c 


voltages_loM() 


Checks the 10V bus. If the voltage has fallen 
too low, this function returns the value 
TRUE: otherwise it returns the value 
FALSE. 


expmnt.c 


\>e_launched() 


Checks for any indications of a launch. 
These can come from the Vibration-activated 
Launch Detector or from the Barometric 
Pressure Switches. 


fputc.c 


fputc() 


The UNIWARE compiler provides the 
standard C output routine printf() to provide 
output to the standard output device. How- 
ever. this routine requires the user to provide 
a routine fputcQ to handle the output of a 
single character to any arbitrary device. We 
only support output by fputc() to the 
RS-232C terminal, so this routine is specific 
to that device. The routine will not output 
a character if, upon checking, it finds there 
is no terminal attached to the serial interface 
port. Thus, when the experiment is operat- 
ing, calls to printf() are of no effect unless 
there is a terminal connected. 


initial.c 


inithard\vare() 


Initializes the six ports on NSC810A #1 and 
u2. 


inout.c 


allow_ctrl_interrupts() 


Processes the special characters CTRL S and 
CTRL Y when read from the keyboard. 
CTRL S is a toggle switch. The first time it 
is pressed, the display halts. The second time 
it is pressed, the display resumes. Subse- 
quently its function alternates between these 
two. CTRL Y invokes the diagnostic sub- 
system. 
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inout.c 


dump() 


Produces a hexadecimal and ASCII dump 
of any desired region of memory. 


inout.c 


echo() 


Sends a single character to the terminal. 


inout.c 


gethe.\() 


Inputs a string representation of a two-digit 
hexadecimal number from the terminal and 
converts it to hexadecimal format. For ex- 
ample, “3a" is converted to 0x3a. 


inout.c 


gethexint() 


Gets a four-digit hexadecimal number in 
string format from the terminal and converts 
it to a hexadecimal word. For example, 
“3ab2" is converted to Ox3ab2. 


inout.c 


getintQ 


Inputs a string representation of a decimal 
integer from the terminal and converts it to 
integer format. For example, ‘*352” is con- 
verted to 352. 


inout.c 


getpageno() 


Asks the user for a page number in bubble 
memory. 


inout.c 


look_ahead() 


This program can see whether a character 
has been input from the keyboard without 
disturbing the input butler. 


inout.c 


portdumpO 


Outputs a string to the terminal, interface 
port. 


inout.c 


termini ) 


Inputs a single character from the terminal. 


inout.c 


testinputl) 


Asks the user for a hexadecimal port address, 
reads that port and displays the data read 
from that port. 


inout.c 


testoutput() 


Asks the user for a hexadecimal port address 
and a hexadecimal byte to be sent to the 
port, and sends it there. 


main.c 


main!) 


First C language subroutine to get control 
after start-up. Decides whether to invoke 
the menu-driven diagnostic routines or to 
run The Yibro-acoustic Experiment. 


mbrk.s 


mbrkl) 


Implements the C language standard library 
function mbrk(). This function was provided 
with the Uniware C Compiler. 


main.c 


memory_dump() 


Asks the user for an address in memory and 
the number of bytes he wants to see dis- 
played. It then provides a hexadecimal and 
ASCII display of the contents of the selected 
area of memory on the terminal. 


main.c 


menuQ 


Displays the first in a hierarchy of menus 
permitting the user to test subsystems of the 
Yibro-acoustic Experiment individually. 
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main.c 


testioQ 


This routine permits the user to perform in- 
put from and output to any port in the sys- 
tem. By "port" we mean here an address in 
the input and output space. 


newio.s 


inputQ 


Inputs a character from a port. Written in 
assembly language, but used like a C lan- 
guage routine. 


newio.s 


output() 


Outputs a byte to a port. Written in assem- 
bly language, but used like a C language 
routine. 


power.c 


power_status() 


Inputs the one-byte status code from the 
power relay subsystem. 


power.c 


power_write() 


Sends a one-byte command code to the 
power relay subsystem. 


power.c 


pw rcnt() 


A menu program which let’s the user read 
the status code from the power relay subsys- 
tem or send commands to it. 


version.c 


version() 


Displays the current version number of the 
control program on the terminal. 
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APPENDIX G. CONTROL PROGRAM DOCUMENTATION 



W e presented a general description of the software as a whole in Chapter 
IV. DESIGN OF THE CONTROL SOFTWARE on page 43. This included a mod- 
erately detailed description of the flowcharts which describe the system, beginning with 
Flowchart 0 in Figure 20 on page 4S. This appendix contains more detailed de- 
scriptions of the operation of each subroutine in the control program. A basic know- 
ledge of the C programming language is assumed. 

We have grouped the functions into two broad categories: 

1. major subroutines, and 

2. support subroutines. 

The descriptions in this appendix are best understood by referring to the source code in 
APPENDIX H. CONTROL PROGRAM SOURCE CODE on page 150. 

In Section A. Major Subroutines and Functions on page 10S we present the major 
subroutines and functions of the control program in an order based roughly on their 
position in the hierarchy of function calls. This section therefore follows the overall 
structure of the control program. 

Referring again to Flowchart 0 in Figure 20 on page 48, we see that the control 
program contains two major parts: 

1. One performs the Vibro-acoustic Experiment. 

2. The other operates a menu-driven system to permit testing of the system on the 
ground. 

Once we have discussed the major subroutines, there will remain numerous lesser 
subroutines which we describe in Section B. Supporting Subroutines and Functions on 
page 121. We provide two tables to make it easier quickly to ascertain the purpose of 
subroutines and their locations in several different source files. Table 8 on page 91 lists 
all subroutines by name, and shows in which MS DOS source files subroutines are lo- 
cated. Table 9 on page 99 lists the contents of each MS/DOS source file in alphabetic 
order by name. 

In general, the program attempts to display many diagnostic messages on the ter- 
minal using the printf() function. This function was supplied with the C compiler, but 
it in turn calls a function called fputc() not supplied with the compiler. The purpose of 
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the subroutine fputc() is to accept a character from the printf() function and to send it 
to the terminal for display. We created this subroutine, and its description is contained 
in Section B. Supporting Subroutines and Functions on page 121. This function al- 
ways checks to see whether there is a terminal attached or not. If not, it makes no at- 
tempt to display any messages on the terminal. Henceforth, whenever we say that 
something will appear on the terminal, it will be understood that this will only occur if 
the terminal is attached. 

A. MAJOR SUBROUTINES AND FUNCTIONS 
1. main() 

This is the beginning point for any C language program. It is called by the 
start-up code, which is written in Z-SO assembly language. The mainQ program first 
initializes pointers to the buffers which will hold data from the bubble memory. There 
are two formats for such data. One is used in page zero of the memory, which is used 
to record the current status of the experiment. The other format is used in all other 
pages of the bubble memory to record all actions and measurements taken during the 
experiment. The buffers are treated both as arrays and as structures. When they are 
treated as arrays, it is easy to transfer the data to or from the bubble memory. When 
they are treated as structures, it is easy to extract individual fields of data. By forcing 
the pointers pagezero and Iog_page to point to the arrays pageO_buffer and log_buffer 
respectively, we can access the data subsequently by using either the pointer to the 
structure or the name of the array as appropriate. 

The niain() program then calls initharduareO to initialize the two NSC810A 
RAM-1 O Timer chips on the controller board. Next it checks to see if there is a ter- 
minal attached by calling checkprt(). The absence of a terminal implies that the appa- 
ratus is now installed in the Space Shuttle and the controller should therefore perform 
the experiment. Therefore, if there is no terminal attached, main() will call e\pmnt(), 
which performs the Vibro-acoustic Experiment. 

If there is indeed a terminal attached, main() calls shut_down_no_log(), whose 
function is to remove power from all subsystems without logging that action in the 
bubble memory. The reason for removing power is to ensure that all the subsystems are 
in a known state at the outset. The reason for not wishing to log this action is that the 
log entries should only be made during the course of the experiment. Since the con- 
troller is about to enter the menu subsystem, it is not going to perform the experiment 
and so no log entry is appropriate. 
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Next main() calls menu(), from which all other testable sections of the control 
program can be selected. The option EXPERI MENTOR permits the menu diagnostic 
subsystem to invoke the program expnintQ later, if the user wishes to do so. This would 
permit him to perform the experiment on the ground and so test its operation. 

2. void inithard\>are(void) 

This subroutine initializes the two NSC810A RAM-I O-Timer chips on the 
controller board. The uses of the pins of port A in each chip are given in Table 4 on 
page 17 and Table 5 on page 17; those of Port B are given in Table 2 on page 15 and 
Table 3 on page 16; and those of port C are given in Table 6 on page 18 and Table 7 
on page 19. 

MDR1 is the Mode Definition Register of the NSC810A ±tl. Writing a 0x00 to 
it puts port A. into basic 1 O mode, which is the simplest method of 1 O supported by 
this chip. 22 

DDRA1 is the Data Direction Register of port A, of the NSCS10A -1. Writing 
OxfT to it causes each of its bits to be configured for output. 

DDRB1 is the Data Direction Register of port B, of the NSCS10A =1. Writing 
OxfT to it causes each of its bits to be configured for output. 

DDRC1 is the Data Direction Register of port C, of the NSCS10A =1. Writing 
0x30 to it causes bits 0 through 3 and bits 6 and 7 to be configured for input. Bits 4 and 
5 are configured for output, although bit 5 is not used in the Vibro-acoustic Experiment. 
Note: this is only a 6 bit port; bits 6 and 7 do not exist. 

TM0T is the register for setting the mode of Timer 0 in NSC810A =1. Writing 
0x00 to it will stop the timer, an action which must be performed before changing its 
mode. Writing 0x25 will cause the timer to produce a square wave without 
“prescaling" and with “single precision". When prescaling is not used, every pair of in- 
put clock cycles is used to advance the timer’s counter by one. When single precision 
is selected, only the low byte of the timer will ever be read. 

T0LB1 and T0HB1 are the registers for the low byte and high byte respectively 
of the modulus for Timer 0 in NSC810 =1. This number serves to initiate the timer 
counter. During subsequent operation, the counter is decremented once every clock 
period. Each time the counter reaches 0, the timer output switches to the opposite state 
and the timer is reloaded. We write 0x07 to the low byte and 0x00 to the high byte, so 
the modulus is 7. This means that after every seven cycles, the clock is reloaded. The 

22 With basic I O. there is no handshaking (see Glossary) with support hardware. 
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reloading consumes a further cycle, and it takes two complete reloads to go through one 
cycle of the output. The period thus is 2 x (7 + 1) = 16 clock periods. The NSCSOO is 
driven by a 4.9152 4- 2 = 2.4576 MHz clock. So 16 clock periods take 6.51 n s, for a 
clock frequency of -g-jj — — = 153.6 kHz. This signal is used as a baud-rate generator 
on the controller board; it is fed to an Intersil 6402 L'ART which further divides the 
frequency by 16, yielding a 9600 baud transmission rate at which to drive the RS-232C 
interface. 

START01 is the start port of Timer 0 in NSC810 #1. Writing anything to this 
port causes the newly programmed timer to start operating. 

MDR2 is the Mode Definition Register of the NSC810A *?2. Writing a 0\00 to 
it puts port A, into basic TO mode. This is the simplest method of I O supported by 
this chip.23 

DDRA2 is the Data Direction Register of port A 2 of the NSC810A -2. Writing 
0x00 to it causes each of its bits to be configured for input. 

DDRB2 is the Data Direction Register of port B 2 of the NSC810A »2. Writing 
0x00 to it causes each of its bits to be configured for input. 

DDRC2 is the Data Direction Register of port C 2 of the NSC810A #2. Writing 
0x31 to it causes bits 1 through 3 to be configured for input. Bits 0. 4 and 5 are con- 
figured for output. Bits 1 and 2 are not in use. Note: this is only a 6 bit port; bits 6 
and 7 do not exist. 

TM02 is the register for setting the mode of Timer 0 in NSC810A =2. Before 
you can change the mode, you must first stop the timer. Writing 0x00 to it does this. 
Writing 0x25 will cause the timer to produce a square wave without “prescaling" and 
with “single precision”. When prescaling is not used, every pair of input clock cycles is 
used to advance the timer’s counter by one. When single precision is selected, only the 
low byte of the timer will ever be read. 

T0LB2 and T0HB2 are the registers for the low byte and high byte respectively 
of the modulus of Timer 0 in XSC810 U2. This number serves to initiate the timer 
counter. Once every clock period, the counter is decremented. Each time the counter 
reaches 0, the timer output switches to the opposite state and the timer is reloaded. 
We write 0x01 to the low byte and 0x00 to the high byte, so the modulus is 1. This 
means that after 1 cycle, the clock is reloaded. Now the reloading consumes a further 
cycle, and it takes two complete reloads to go through one cycle of the output. The 

23 With basic I O, there is no handshaking (see Glossary) with support hardware. 
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period thus is 2 x (1 + 1) = 4 clock periods. The NSCSOO is driven by a 
4.9152 + 2 = 2.45/6 MHz clock. So 4 clock periods take 1.628 ,us, for a clock frequency 
°f "j 6 -, 8 us = 614.4 kHz. This frequency is used as a clock for the National Semicon- 
ductor ADC0816 Analog-to-digital (A, D) Converter. 

When driven by a clock of frequency 640 kHz, the A Ds normally can complete 
the conversion of an analog signal to a digital value in around 100 fis. The frequency 
we are using here, 614.4 kHz, is close to this, so we should get comparable performance. 
[Ref. 19: pp. 8-71 to S-81] 

START02 is the start port for Timer 0 in NSC810 £2. Writing anything to this 
port causes the newly programmed timer to start operating. 

Finally, we clear bits 4 and 5 of port C 2 by writing 0x03 to the port C 2 
“bit clear” register. BCLRC2. The purpose of this is to ensure that power to the bubble 
memory remains off, and to ensure that the bubble memory’s reset line is held low. 
Strictly speaking, this should not be necessary, since the registers of the NSC810 are in- 
itialized to be zeros. However, we take nothing for granted, and this precaution helps 
preclude the loss of the bubble memory’s contents that might result from an improper 
application of power. 

3. char checkprt(void) 

This function inspects the TERMON bit (bit 3) of Port C in NSCS10 ±*2. This 
bit is a 0 if there is an RS-232C terminal connected to the controller. It is a 1 otherwise. 
The function returns a TREE in the first case; a FALSE in the second. 

4. void sliut_do\>n_no_log(void) 

This subroutine removes power from any subsystems which are currently on. 
It does not record the fact in the bubble memory log. which is the only respect in which 
it differs from the subroutine shut_down(). It obtains a character describing the position 
of each of the relays in the power subsystem by calling the function power_status(). The 
series of if statements which then follows causes successive bits of that character to be 
tested. Every time one of these bits indicates that a relay is in the ‘on’ position, that 
relay is turned off with a call to po«er_nrite(). 

5. char menu(char experiment_flag) 

This function is at the top of a hierarchy of diagnostic subroutines. The func- 
tion calls the sub-function versionO whose only purpose is to display the number and 
date of the current version of the control program. It next presents a menu from which 
the user can select any of a number of categories of diagnostic tests. The function 
termin() is used to obtain a single character from the keyboard, that character is con- 
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verted to lower case by tolower() (if it was not already in lower case), and the character 
is displayed on the terminal. That character is used by the switch to select a case state- 
ment appropriate to the user’s choice. The entire process will be executed repetitively. 
The only way to leave it is by choosing to run the experiment. If this is done, the 
function expmntQ gets control. 

To cause a software reset, the program executes an assembler instruction jp 0. 
This function has the effect of restarting the controller at address 0 of memor\ r . This is 
the same address at which execution begins when power is first applied. All variables 
are set to their initial values, other start-up functions are performed as usual, and the 
program main() begins to execute anew. 

The function rtc() accesses the real-time clock diagnostic subroutines. 

The function pwrentQ access the power subsystem diagnostic subroutines. 

The function bubmenuf) accesses the diagnostic subroutines which can be used 
to test the bubble memory module. The tests available through this selection all are very 
low-level tests. 

When choice E is made, the controller enters a for loop and successively reads 
each of the analog-to-digital (A D) converter channels by calling the sub-function 
adread(). This function returns an eight-bit number addata which is proportional to the 
value read by the A D converter. A call to printff) displays this number along with a 
descriptive adcaption (defined in the file global.c). The first three readings are known to 
be voltages. The remaining values are temperatures, so they are displayed in a slightly 
different format. Furthermore, depending on which channel the A D converter read, the 
number read may represent different magnitudes in the measured units. For example, 
the number 102 may represent 4V or 270° K, depending on which channel was read. 

Voltages, fall either into the range [0, 10]V or the range [0, 20]V. Temperatures 
fall into the range [0, 500]°K. The function adtoint() converts the value read by the AD 
converter into its value in degrees Kelvin or in hundredths of volts, whichever is appli- 
cable. The converted value is then displayed using the printf() function. To get two 
converted readings per line, carriage returns are placed at the end of every’ other dis- 
played value, only. 

There are two possibilities if choice F is made. One is that experimentjlag is 
TRUE; the other is that it is FALSE. The former case always occurs when menu() is 
called the first time, from main(). However, it is possible to interrupt the execution of 
the experiment and to enter the menu subsystem recursively. It is not possible to make 
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menu choice F under these circumstances. To restart the experiment would require first 
making choice A to reset the system. 

The function testioQ is called when choice G is made. Its purpose is to allow 
low-level testing of the peripheral devices. 

The function memory _dump() is called when choice H is made. Its purpose is 
to display the contents of the controller’s memory. This is useful only in debugging the 
software. 

The function log_menu() is called when choice I is made. Its purpose is to allow 
the contents of the bubble memory to be displayed. It differs from the functions called 
when choice D is made in that the contents of the bubble memory are regarded by 
Iog_menu() as formatted data areas, not just as collections of characters. This means 
that the data stored in the bubble memory during execution of the experiment can be 
displayed in an intelligible format, and the experiment's status, stored in page 0. also can 
be displayed in a readable format. The function log_menu() also allows the status to be 
modified in order to alTect the manner in which the controller performs the experiment. 
The details of how to do this are contained in Chapter V. HOW TO GET THE EX- 
PERIMENT READY FOR A LAUNCH on page 63. 

6. void version(void) 

This function displays the number and date of the current version of the control 
program on the terminal. 

7. void rtc(void) 

This function displays a menu of functions related to the operation of the real- 
time clock. The clock can be read, set or tested from here. The method of displaying 
the menu, reading the choice, and taking the appropriate action is identical to that used 
in the function menu() described earlier. The function rtc() differs only in the choices 
and actions possible. 

Choice A causes the function clockread() to be called. It stores the current date 
and time in a structure whose pointer is clock. The function dump_c!ock() is called next; 
it displays the date and time on the terminal. This choice is provided to verify that the 
real time clock is working correctly. 

Choice B causes the function c!ockset() to be called. It permits the user to set 
the current date and time. The real time clock is powered by its own battery, so this 
option should seldom be required. 
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Choice C causes the function testtimeout() to be called. Its purpose is to permit 
the operation of the timeout feature to be tested. It is useful only in debugging the 
software. 

8. void clockread(struct datetime *your_clock) 

This function inputs the binary-coded-decimal (BCD) time from the real-time 
clock and places the results in a structure pointed to by your_clock. If the current 
number of seconds changes between the start and end of reading, it means that the clock 
has advanced to a subsequent time. To preclude the reading of an incorrect time, the 
input sequence is repeated in the hope that an advance will not occur again. This can 
happen up to 10 x TRIES times. 

For example, suppose the time were 9:59:59 when the seconds and minutes were 
read. The clock might advance to 10:00:00 before the hours were read. Then the time 
read would appear to be 10:59:59. which is wrong by one hour. By reading it again, we 
may avoid this error, but there is no obvious way to guarantee it without stopping the 
clock. Doing so would be disadvantageous, since it would affect timing relationships in 
an unpredictable manner, so we chose not to stop the clock but to take our chances and 
try reading it again. 

9. void dump_clock(struct datetime *clock) 

This function displays on the terminal the time stored in a structure pointed to 
by clock. To do this it calls the function bcd_int(), which converts the BCD values in the 
date and time provided by the real time clock into decimal equivalents. These converted 
values are then displayed by the function printf(). 

10. void clockset( struct datetime *clock) 

This function first calls the function get_time() to ask the user for the current 
date and time. The time specified is left in the structure pointed to by clock. The func- 
tion clockset() then stores the date and time in the real-time clock by repeated calls to 
outputQ. 

1 1. void testtimeout(void) 

This allows the user to test that the time-out function is working. The time-out 
function enables the control program to continue normal processing while waiting for 
some amount of time to elapse. 

For example, after launch the controller will monitor the Solid State Date Re- 
corder (SSDR) for completion of recording. However, it will also initialize a time-out 
of three minutes, and will stop waiting for the SSDR if this time should elapse before the 
SSDR signals completion. The testtimeoutQ function allows the user to test the time-out 
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feature for any number of seconds, minutes or hours. A menu is presented to the user 
using the same method already outlined in the description of the function menu(). The 
units of the specified delay depends on the menu choice made. The function getintQ is 
called to obtain the number of units of delay that the user wants. The current time then 
is obtained with a call to clockread(). and it is displayed on the terminal with a call to 
dump_clock(). The timeout() function then is called to initialize the delay according to 
the number of delay units specified by the user. A while loop calls timeout() repeatedly 
with the NULL parameter. This parameter causes the timeout() function to check to see 
if the desired wake-up time has arrived or not. As long as it has not yet arrived, that 
function returns FALSE and the program continues to loop. If other statements were 
provided before the end of the loop, then they would be performed repeatedly until the 
function timeout!) finally returned TRUE, signifying that the desired amount of time had 
elapsed. The function testtimeout() has no such instructions, but when the delay period 
is over, it rings the bell and once again reads and displays the current time. 

12. void pwrcnt(void) 

This function displays a menu to allow the user to test the operation of the 
power board relays. Any of the attached units, such as the SSDR. can be switched on 
or off from this menu. The method of displaying the menu is the same as that already 
given in the description of the function me»u(). Any menu choice from A through J is 
converted to a number in the range [0,9] by subtracting the character 'a' from it. 1 his 
number is then used as an index into array relay to select the command to be issued to 
the power control subsystem through a call to the function power_»rite(). Choice K 
causes the power subsystem’s status to be read with a call to power_status() and then 
displayed on the terminal. The meaning of this byte is shown in Table 2 on page 15. 

13. void bubmenu(void) 

This function displays a menu which lets the user test the bubble memory’ on the 
controller circuit board. The method of displaying the menu is the same as that already 
given in the description of the function menu(). 

Choice A causes a call to bub_on(). 

Choice B causes a call to bub_off(). 

Choice C attemps to initialize the bubble memory with a call to bubinit(). The 
results of this attempt are then explained with a call to printf(). 

Choice D causes a call to bubcmdmenu(). 
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Choice E causes a call to testpattern(). The character string tenipbuffer is pro- 
vided to this function for storage of a string of characters entered by the user from the 
keyboard. 

Choice F causes the contents of tempbuffer to be displayed in ASCII format. 

Choice G causes the contents of tempbuffer to be displayed in hexadecimal for- 
mat. This would be useful if the buffer had been loaded from the bubble memory and 
if it contained unprintable characters. Such would be the case if the contents of the 
bubble memory had been generated by performing the experiment, since the experiment 
formats the data in characters which may not all be capable of being displayed. 

Choice H calls getpageno() to ask the user which page of the bubble memory 
he wishes to access. It then calls bubioQ to transfer the contents of the buffer into that 
page of the bubble memory. 

Choice I calls getpagenoQ to ask the user which page of the bubble memory he 
wishes to access. It then calls bubioQ to transfer the contents of that page of the bubble 
memory into the buffer. 

Choice J causes a call to rdstatregf), which reads and displays the contents of 
the bubble memory controller’s status register. The format of this register is discussed 
in detail in [Ref. I]. 

14. char bub_on(void) 

This function applies power to the bubble memory on the controller circuit 

board. 

15. void bub_off(void) 

This function removes power from the bubble memory on the controller circuit 

board. 

16. char bubinit(void) 

This subroutine initiates the bubble memory on the controller circuit board. 
Power must have been applied first. The sequence of commands is described in 
[Ref. T. pp. 38-39b]. It is as follows: 

1. Issue the B ABORT (abort) command to the bubble memory. 

2. Set up the parametric registers, pointing to page 0 of the bubble memory. 

3. Issue the BINIT (bubble initialize) command. 

4. Issue the BFIFORESET (bubble FIFO reset) command to reset the first-in, first- 

out (FIFO) buffer in the controller's bubble memory. 

5. Transfer 40 Oxff characters to the FIFO buffer in the bubble memory. 
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6. Issue the B\\ RBLREG (bubble write boot loop register) command. At this point, 

the bubble memory is ready for reading and writing. 

17. void bubcmdmenu(void) 

This subroutine allows the user to issue any of the following commands to the 
bubble memory, one at a time: 

1. Abort 

2. Load parametric registers 

3. Initialize 

4. Reset the FIFO buffer 

5. Perform the transfer of 40 Oxff characters to the FIFO 

6. Write the boot loop register 

These commands are issued by bubinitO, but are provided separately here to permit de- 
tailed testing of the initialization process. 

18. void testpattern(char buffer[ J) 

This subroutine permits the user to fill a buffer in RAM with characters to be 
written to the bubble memory. L'p to PAGELENGTH characters can be written at a 
time. Its purpose is to enable the user to verify that data can be written to the bubble 
memory and read back successfully later. 

This subroutine begins by placing a 0 in the variable c. It asks the user to enter 
a string of characters from the keyboard, and then enters a loop. It will continue reading 
up to PAGELENGTH characters. If it encounters a carriage return, it will place blanks 
in the remainder of the buffer. 

19. void sho\»bubbuff(char buffer! J, char mode) 

This subroutine will display the contents of buffer either in ASCII format or in 
hexadecimal representation, according to the value of mode. This parameter can be ei- 
ther ASCII or HEX. The ASCII format would be suitable if it were known that the 
bubble memory page buffer contained only printable characters, as it would if it had 
been filled by testpatternO- The hexadecimal format would be suitable if it were known 
that the bubble memory page previously read contained unprintable characters, or if the 
contents were unknown.24 



24 It may be unwise to risk sending potentially unprintable characters to the terminal, since 
some of them have surprising results, such as clearing the screen. 
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20. char bubio(char command, int page, char *buffer) 

This subroutine permits reading from or writing to any page of the bubble 
memory. Pages can fall in the range 0 through 8191. Commands can be either one of 
BREAD or BWRITE. The data is placed into or read from the buffer pointed to by 
buffer. 

To operate the bubble memory when the temperature falls below 10° C may- 
cause its contents to be destroyed. A call to the function colder_than() precludes this 
from happening. If that function returns TRUE, then it must be too cold. The function 
bubio returns a FALSE to indicate that it was unsuccessful in accessing the bubble 
memory. 

To minimize power consumption, the subroutine applies power to the bubble 
memory before the operation begins and removes it again at the end of the transfer. It 
calls bpageset() to set the parametric registers so as to allow the correct page of bubble 
memory to be transferred. It then calls bubread() or bub\\rite() as appropriate. After the 
transfer is completed, the subroutine reads the bubble status register to see if the oper- 
ation was successful or not. The bubio() subroutine returns a TRUE if the transfer 
worked; FALSE otherwise. 

21. void rdstatreg(void) 

This subroutine lets the user check the contents of the bubble memory status 
register. The meaning of its contents is shown in Table 10 on page 119. To obtain the 
status code, this subroutine calls the function input(), which reads the contents of the 
port BUBCTRL (port 0x41). This port yields the status code, which is then converted 
to hexadecimal format using the function ctoh() and is displayed. 

22. void expmnt(void) 

This function performs the experiment. Its first task is to call initialize(). This 
subroutine retrieves the current mission status from page 0 of the bubble memory. If 
there is no more room in the bubble memory’, a value of FALSE will be returned. Al- 
though the experiment will be performed, no entries can be made in the log. The Solid 
State Data Recorder (SSDR) may therefore still be able to record acoustic data suc- 
cessfully. There will be no log of the events as they occur, however. 

The function expmntO next checks to see whether the flag full_experiment in 
page 0 is TRUE or FALSE. If not, the function short_experiment() is called to perform 
the abridged experiment. Otherwise, the unabridged experiment is to be performed by 
expmntQ. 
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Table 10. BIT ASSIGNMENTS FOR THE BUBBLE MEMORY CONTROLLER 
(BMC) STATUS BYTE: From [Ref. 1 : Chapter 3. p. 12}. 



Bit 


Value 


Meaning 


0 


1 


FIFO Ready. The FIFO buffer is ready 
to transfer data. 




0 


The FIFO buffer is not ready. 




1 


Parity error. 




0 


No parity error. 


2 


1 


Uncorrectable error. 


0 


No uncorrectable error. 




1 


Timing error. 




0 


No tinting error. 


A 


1 


OP FAIL. The current operation failed. 


0 


No OP FAIL. 


5 


1 


OP COMPLETE. The current operation 
is complete. 




0 


No OP COMPLETE. 


6 


1 


Busy. This means that a command has 
been accepted but is not yet complete. 
The BMC stays busy throughout a data 
transfer. 




0 


Not busy. 



The next step is to initiate the sweep phase, if this has not already been done. 
Recall that this might have occurred if power had been removed from the controller at 
an earlier time, whether by human intervention or through a fault. If the sweep phase 
is required, the function do_st>eep() is called to do it. 

Next the controller must decide whether or not a launch has already occurred. 
It consults the launchdone flag in page 0 of the bubble memory. If this flag is TRUE, 
the Space Shuttle launched earlier. Otherwise, w r e must listen for the activation of the 
Auxiliary Power Units (APUs) by calling the function listen(). When this function 
completes its job, it will return a mission status. This can take on any one of the fol- 
lowing values: 

DAPUON The activation of the APUs has been detected. 
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DLAUNCH 



The activation of the APL's was never detected, but launch was 
detected. This may be the case if the Vibration-activated 
Launch Detector detects the vibration associated with the ig- 
nition of the solid rocket motors or if the Barometric Pressure 
Switches detect an ascent. 

DUSERNOAPU The system is being tested on the ground and the user depressed 
a key while the system was listening for the APL's. This pro- 
vides a means of terminating the period of waiting for a signal. 

If listen() detects anything, then the function expmnt() will turn on the Analog- 
to-Digital (A/D) Converter by sending the code ADON to the function pcmer_write(). 
It then will turn on the Solid State Data Recorder (SSDR) by sending the code 
SSDRON to the same function. Both these actions will be logged in the bubble memory 
by the function logevent(). If listen() had returned the mission status code DAPLON, 
then expmntQ commands the SSDR to enter scroll mode, which means that it will start 
recording ambient noise. Since the APLs are now on, we know that a launch must oc- 
cur within seven minutes, or the mission will be scrubbed by NASA. We want to wait 
at least this long. To be on the conservative side, we begin a ten minute time-out period, 
during which we wait for some indication of a launch. The function \\e_launclied() will 
return the mission status code DLALNCH if it detects such an indication. The function 
look_ahead_discard() checks to see whether, during ground testing, the user has depressed 
a key during this time-out period. If so. we regard the time-out as having been com- 
pleted. This permits accelerated testing of the system without always waiting for the end 
of the full time-out period. Eventually one of the two conditions will have occurred and 
the waiting period will end. 

If the launch had occurred at some earlier time, we would end up in the next 
section of the code in expmnt()- The fact that a launch had occurred previously would 
be logged by calling logevent() with the argument PRIORLALNCH, and the mission 
status would be set to this same value. 

The next section of code is executed only if a launch is in progress. The SSDR 
is commanded to leave scroll mode and enter launch mode. The SSDR has only enough 
memory to record two minutes of noise after a launch. We initiate a three-minute 
time-out period so that if the SSDR fails to report completion, we will still be able to 
go on to other tasks. During the period of this time-out, w r e want to ensure that a 
launch is recorded in page 0 of the bubble memory, if in fact a launch has occurred. If 
the launchdone flag in page 0 has not been made TRUE yet, expmtn() calls 
baro_s\vitch( ). This funcion will check the condition of the barometric switches. If either 
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one has fired, it will make the launchdone flag TRUE. The barometric switches are re- 
garded as the only thoroughly reliable indication of a launch. 

We will terminate the launch phase either because the SSDR reports completion 
or because the time-out has occurred. We record whichever of these is the case by call- 
ing logeventQ with either the argument DOPCOMP or DNOOPCOMP, respectively. 

Unless expmnt() detected that the launch had been aborted, the experiment will 
next invoke the function post_Iaunch(). This function will keep control until power is 
removed from the experimental apparatus. 

B. SUPPORTING SUBROUTINES AND FUNCTIONS 

The major modules of the control program were described in Section A. Major 
Subroutines and Functions on page 108. Subroutines not described there are described 
here. They are listed alphabetically by the name of the source file in which they are de- 
fined. and alphabetically by function name within file name. 

1. File bubble.c 

a. void bpagesetfint page) 

This subroutine initializes the parametric registers in the bubble memory. 
There are five of these, and they contain information about the bubble memory's status 
and about upcoming data transfers. The meaning of the fields within these registers is 
given in Table 1 1 on page 122. A complete description of their use is given in [Ref. 1: 
pp. 7-12). from which the information in Table 11 on page 122 is taken. 
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Table 11. CONTENTS OF THE PARAMETRIC REGISTERS IN THE BUBBLE 



MEMORY CONTROLLER: Extracted from [Ref. 1 : Chapter 3, pp. 

7-12). 



REGIS- 
TER AD- 
DRESS 


REGISTER 

NAME 


BIT 

FIELD 


CONTENTS 


0x0b 


Least Significant 
Byte of the Block 
Length Register 


0-7 


Least significant eight bits of the 
block length. The block length 
is the number of pages trans- 
ferred to or from the bubble 
memory at one time. 






0-2 


Most significant three bits of the 
block length. Thus there are 1 1 
bits in the block length, permit- 
ting up to 2“ = 204S pages to be 
transferred at once. 






3 


Unused 


0x0c 


Most Significant 
Byte of the Block 
Length Register 


4-7 


The number of Formatter Sense 
Amplifier channels available. 

The binary value 0001 is appro- 
priate here because we have only 
one bubble memory attached. 
Two channels are used to com- 
municate with the bubble mem- 
ory. With a single bubble 
memory available, the page size 
is defined to be 64 bytes in 
length. 
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0 


Interrupt enable (normal). We 
set this to 0 because we are not 
using interrupts to communicate 
with the bubble memory control- 
ler. 






1 


Interrupt enable (error). We set 
this to 0 because we are not using 
interrupts to communicate with 
the bubble memory controller. 






2 


Direct Memory Access (DMA) 
Enable. We set this to 0 because 
we are not using DMA with the 
bubble memory. 






3 


Reserved by Intel. 


OxOd 


Enable Register 


4 


Write Bootlooop Enable. The 
bootloop is used internally to the 
bubble memory. It need never 
be rewritten except as part of a 
diagnostic test. We let this be 0 
since we don't want to modify the 
bootloop. 






5 


Enable Read Corrected Data 
(RCD). We set this to 1 to per- 
mit the format sense amplifier to 
apply error correction to errone- 
ous data. If the error is uncor- 
rectable. then the erroneous data 
will be transferred to the host 
processor. 






6 


Enable Internally Corrected Data 
(ICD). Setting this causes the 
bubble memory to notify the host 
processor of its inability to cor- 
rect erroneous data. In this case, 
it does not transfer that data. 

We set this to 0 and don't use the 
feature. 






7 


Enable Parity Interrupt. W'e set 
this bit to 0 because we are not 
using interrupts. 


OxOe 


The Least Signif- 
icant Byte of the 
Address Register 


0-7 


The least significant byte of the 
address. The address refers to the 
particular page within the bubble 
memory’ where data transfers are 
to begin. Since we are using a 
block length of one page, this 
actually addresses the single page 
we are transferring. 
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